Modules, Sub-modules & adapters
Quick start

OneView documentation

Modules, Sub-modules & adapters

How licensed Modules and Sub-modules become available and when vendor setup is required.

Modules and Sub-modules

A Module is a licensed OneView product area. A Module can contain one or more separately licensed Sub-modules. For example, KYC is a Module and BVN and NIN are its Sub-modules:

KYC
├── BVN
├── NIN
├── Driver's License
├── CAC
├── International Passport
├── TIN
├── PEP Screening
└── Sanction Screening

The client navigation uses the Module name as its group heading. When a licensed Module has Sub-modules, each licensed and installed Sub-module appears as a link inside that group. For example:

KYC
├── BVN
├── NIN
├── Driver's License
├── CAC
├── International Passport
├── TIN
├── PEP Screening
└── Sanction Screening

PEP Screening and Sanction Screening are separately licensed and configured Sub-modules. They use independent provider operations and are never combined into one AML request. Each requires its own compatible connection and may have separate provider pricing and usage consequences.

Prembly and the hosted production OpenSanctions services can provide these screenings when their released adapters are available. OpenSanctions uses separate pep-screening and sanction-screening services. A client-supplied commercial OpenSanctions API key and provider-approved data-transfer terms are required. Self-hosted OpenSanctions yente is not a supported OneView v1 connection.

A Module or Sub-module appears only when it is included in the current license and the installed OneView version supports it. A user must also have the permission required by that page. The Dashboard remains available to every signed-in user even when no optional Module is available.

Technical keys and supported addresses

New catalogue identities use lowercase kebab-case technical keys. Some released KYC Sub-modules retain historical immutable keys containing underscores, including drivers_license and international_passport. Their supported browser addresses are therefore /app/kyc/drivers_license and /app/kyc/international_passport.

Use the exact address displayed by OneView or documented for the installed release. Do not replace underscores with hyphens, derive a key from a display name, or assume that a browser address establishes an external API request contract. Display names can change without changing a supported technical identity.

Modules do not need to contain Sub-modules. A Module without Sub-modules still has its own navigation group, while the installed OneView version determines the pages shown inside it. Licensing a Module does not add pages to an older installation that does not support that Module.

When a vendor connection is required

Vendor requirements belong to the Sub-module that performs the vendor-backed operation:

  • Required — the Sub-module needs an active compatible vendor connection before its operation can run.
  • Optional — the Sub-module works independently, but supported vendor services may add related functionality.
  • Not used — the Sub-module does not require vendor setup.

A Module without Sub-modules may also work entirely within OneView and require no vendor connection. Follow the page's connection guidance rather than assuming every licensed Module requires a provider. If a required connection is missing, follow Vendor connections to configure an available service.

Adapters

A vendor is a provider such as Prembly. A vendor service is one API offering from that provider, such as BVN Basic or BVN Advanced. Each adapter-backed service belongs to a Sub-module. A vendor may therefore expose several services for the same Sub-module and services for other Sub-modules.

An adapter is OneView support for one exact vendor service and Sub-module. Administrators cannot upload custom connector code through the dashboard.

Each adapter defines:

  • One vendor, service, Sub-module, and supported environments.
  • Required credential fields.
  • Request validation.
  • Safe stored summaries and normalised results.
  • Normalised result and error mapping.
  • Per-connection rate, concurrency, and circuit policy.
  • Whether replay-safe automatic retry is explicitly supported and, when it is, a maximum of two or three total attempts.

Retry is denied unless an adapter explicitly declares the operation idempotent under its reviewed contract. All attempts and backoff share the synchronous 15-second total execution deadline. See the Synchronous API for the request evidence fields, default runtime limits, usage boundary, and metadata-only audit behavior.

Availability lifecycle

A Module or Sub-module becomes visible only after both its license and the installed OneView version support it. For Sub-modules that require or optionally use vendors, a vendor service becomes configurable only when all of these are true:

  • The vendor and service are available to the installation.
  • The installed OneView version supports the exact vendor service and adapter version.
  • The parent Module and Sub-module are included in the customer's license.
  • The service supports at least one environment available to the installation.

A vendor status or service change reaches an installation after its next successful license refresh. An older installation may need a software update before it supports a newly released service.

Users need verifications:read to see metadata-only licensed Sub-module history in the browser. Result previews and stored normalized result details additionally require verifications:results:read, shown as View verification results in the Roles interface. See Verification history. A user with verifications:execute can open the required Sub-module page and select New Verification. The Sub-module is already selected; the user chooses a Vendor connection, optionally enters Purpose, completes the service fields, and selects Run verification. The same drawer shows Verification completed, normalized status, and Normalized result in a read-only structured JSON view.

External applications use an active API Service Account and follow the exact Synchronous API contract. Never infer request fields from a Module or Sub-module name; use only the fields OneView documents for the selected released service.

A licensed Module or Sub-module is not visible

  1. Open License & Updates → License and confirm that the parent Module and expected Sub-module are listed.
  2. Select Refresh when the license was recently issued or changed.
  3. Sign out and sign in again after a successful refresh.
  4. Open License & Updates → System updates and check whether an approved update is available.
  5. If an update is available, ask the host administrator to apply the displayed update instructions, then sign in again.
  6. If the installed version is current but the item remains unavailable, ask the OneView support contact to confirm which released version first supports the purchased Module or Sub-module. Share the installed version and public license ID only.

Do not reinstall OneView, recreate the license, or configure an unrelated vendor connection merely to make navigation appear. A Module or Sub-module that works without adapters does not require vendor setup.