When you are integrating identity verification into your product, the first question is always the same: do you use the SDK or the API? Teams often treat this as a technical detail to sort out later, then end up rebuilding a verification flow midway through a project because they picked the wrong one. The right answer depends on how much of the user experience you want to own and how much you want Dojah to handle for you.

What the REST API Actually Does

Dojah's REST API lets your backend talk directly to Dojah's verification engines. There is no frontend involved on Dojah's side. Your server sends a request, Dojah runs the check, and your server gets a response back. That makes the API the right fit when you are running background checks or single data lookups that a user never needs to see, like validating a BVN before approving a transaction or re-verifying an existing user during a routine audit.

Because everything happens server-side, you are also fully responsible for the interface. If you want a verification screen, you build it yourself.

How Dojah Secures API Access

API access is locked down at the network level through IP whitelisting. You restrict calls to specific IP addresses on your VPS, and any request from an unapproved address gets blocked, even if someone has your credentials. 

This matters most for teams handling sensitive verification data where a leaked key alone shouldn't be enough to compromise the integration.

Dojah also separates testing from production through two distinct environments. The sandbox returns dummy responses, so your team can build and test request logic without touching real identity data or paying for verifications that don't count.

 Production connects to live databases and bills for every check it runs. Keeping these separate means a bug in staging can't accidentally run up your bill or return a real user's data where it shouldn't.

How Apps, Authentication, and Webhooks Work Together

Dojah organizes API traffic through an "Apps" structure inside the dashboard. Instead of routing every request through one global channel, you create separate Apps for different products, client bases, or operational branches, which makes it far easier to search, filter, and audit activity by App ID when something needs tracing back.

Every API call needs two credentials: the App ID, which identifies your specific setup, and an Authorization header carrying your secret key, which proves your server has the right to make the request. Both are generated and managed from the Developer section of the dashboard.

Not every verification resolves instantly. For checks that take time to process, Dojah acknowledges your initial call right away, then sends a webhook payload to your system once the result is ready. 

Your app listens for that webhook and triggers whatever comes next, updating an account status, unlocking a feature, without polling the API over and over to check if it's done yet. Webhooks can be registered through a dedicated endpoint or directly in the dashboard.

What the SDK Handles That the API Doesn't

Where the API is backend-only, Dojah's SDKs give you a pre-built interface that runs client-side, inside a browser or mobile app.

 Instead of designing your own verification screens and managing media capture flows yourself, the SDK renders Dojah's hosted UI and handles the entire user interaction end to end: collecting documents, capturing liveness, and making the underlying API calls for you.

Security still holds up on the client side. SDK widgets only ever need an App ID and a Public Key. Your secret key stays on your server, where it belongs.

Dojah's SDK coverage spans:

• Web: JavaScript Web SDK, React SDK
• Cross-platform mobile: React Native SDK, Flutter SDK
• Native mobile: iOS SDK (Swift), Android SDK (Kotlin)

Choosing Between SDK, API, or Both

Most teams don't need to pick one path for their entire product. The decision is really about matching the tool to what each part of your flow needs to do.

Take a lending platform as an example. At signup, a new borrower needs to submit an ID and pass a liveness check before they can apply for a loan. That's a user-facing flow, so the SDK carries it, rendering the upload screen, capturing the liveness selfie, and returning a pass or fail without the platform building any of that interface itself.

Three months later, the same platform wants to re-screen every active borrower against updated AML watchlists before renewing their credit lines. No user is present for this. It runs as a scheduled job on the backend, calling the API directly, checking hundreds of records overnight, and flagging anything that needs a second look. Same platform and underlying identity infrastructure, two different tools.

That's the pattern worth remembering: the SDK shows up wherever a user needs to interact with a verification step, and the API runs wherever a check needs to happen without one.

Getting Started

Dojah backs both paths with a 99.9% uptime guarantee and a support team for integration questions. Client libraries are available for Go, TypeScript, C#, Python, PHP, Java, and Kotlin, letting most teams authenticate and run a first live call in under 5 minutes, with full implementation typically done in under 10 minutes using the developer documentation.

Whether your team needs a hosted verification screen or a background check running on your server, the integration path is already built.

 Start with the documentation to see how it fits your stack, or sign up on Dojah to get your API keys and start testing in the sandbox today. 

FAQs

1. Can I use the SDK and API together? Yes. Many teams use the SDK for onboarding and the API for backend re-verification or admin-triggered checks on existing users.

2. Do I need a backend to use the SDK? You still need a backend to store your secret key and handle any server-side logic, but the SDK removes the need to build your own verification UI.

3. Is there a cost to testing in sandbox? No. Sandbox calls return dummy data and don't connect to real identity databases, so testing doesn't incur charges.

4. What happens if a webhook fails to deliver? Dojah retries failed webhook deliveries automatically. If a webhook still doesn't come through, you can query the verification status directly through the API using the reference ID from your original request.

5. Can I switch from SDK to API later without rebuilding my flow? Yes. Since both paths connect to the same verification engine, moving a check from the SDK to the API means changing how you trigger the request, not the underlying logic or the data your platform receives back.