API Integration
How to authenticate, which checks you can request today, and the recommended pattern for connecting your backend to Identity.
Authentication
Every request to the Identity API is authenticated with an organization API key. Keys are created from the Identity console by an admin on your team, and are scoped to either your sandbox or your live environment, so a sandbox key can never be used to run a live check.
You can send the key as an x-api-key header, or as a standard Authorization bearer header. Both are accepted the same way.
Key format
- remllo_sk_test_... for sandbox keys, remllo_sk_live_... for production keys
- keys are shown once at creation time and can be rotated from the console without downtime, since the old and new key both work until you confirm the rotation
- every mutating request should also carry an Idempotency-Key header so a retried request cannot create duplicate verification work
# Either header works
x-api-key: remllo_sk_test_EXAMPLESELECTOR12_examplesecretvaluegoeshere
# or
Authorization: Bearer remllo_sk_live_EXAMPLESELECTOR12_examplesecretvaluegoeshereAPI keys are long-lived credentials, not session tokens. Generate and use them from your backend only, never from a browser or mobile app.
What the API handles
- create direct KYC and KYB verification requests
- create and fetch verification sessions
- fetch verification, subject, business, wallet, artifact, and document records
- register evidence artifacts and complete upload lifecycle actions
- configure webhook endpoints and inspect delivery history
Checks you can request today
Identity routes each check to whichever verification source is configured for your organization and the check type requested. The specific checks available depend on your plan and country coverage, but the following capabilities are live today, not just planned.
Individual identity checks
- BVN lookup
- NIN lookup
- virtual NIN lookup
- phone number verification
- bank account verification
- voter’s card verification
- tax identification number (TIN) verification
- driver’s license verification
- international passport verification
- government ID verification for supported countries outside Nigeria
- document verification, with or without a face match step
- standalone face match
- liveness check
Business and screening checks
- company or business registry lookup
- sanctions list screening
- politically exposed person (PEP) screening
Not every check is available in every country, and coverage can change as verification sources are added. Confirm the exact checks and countries enabled for your organization before finalizing your integration.
Recommended implementation pattern
- Create a direct verification request or verification session from your backend.
- Pass your own customer or business reference into the request.
- Submit the required verification data and evidence through the API or console flow available to your organization.
- Consume webhooks so your platform updates customer state without polling.
Let the customer’s product own activation or approval in their core application. Identity should provide the trust decision and supporting evidence summary, not assume control of the customer’s business workflow.
Idempotency and retries
Non-GET API requests should use an idempotency key so retries do not create duplicate verification work. This is especially important for session creation, check creation, wallet-impacting operations, and evidence lifecycle actions.