How to Integrate an eKYC API Into Your App: PH Guide

Integrating an eKYC API means wiring five checks into your onboarding: capture the ID, extract its data with OCR, validate the data against official records, confirm a live person with liveness detection, and compare the user’s face with the photo printed on the card. For Philippine users, plan around PhilSys, LTO, SSS, and other local IDs, use an SDK for camera capture, call verification from your backend, and design for retries and manual review from day one.

What an eKYC API Does

An eKYC API turns a manual identity check into a set of machine calls. Instead of a staff member looking at a photo of an ID, your app sends images and data to a verification provider and gets structured results back.

Most providers expose several services rather than one big endpoint. That design is useful, because each check answers a different question.

• OCR: what does this ID say?
• Record validation: does an official source confirm those details?
• Liveness: is a living human taking this selfie at this moment?
• Face comparison: is that person the owner of the ID?
• Face search: has this face already registered under another account?

So your job as the integrator is to chain these calls in the right order, store the results safely, and turn them into an onboarding decision.

Reference Flow for Philippine Onboarding

Below, then, is the flow most Philippine fintechs, lenders, and platforms end up with. Your product may skip or add steps, yet the order rarely changes.

1. ID capture (client). First, the app guides the user to photograph the front of their ID, checking glare, blur, and framing before upload.
2. OCR (server). Next, your backend sends the image for extraction and receives structured fields like the holder’s name and card number.
3. Record validation (server). Then you submit the extracted fields for validation against the relevant source, for example PhilSys for a national ID or LTO for a license.
4. Selfie and liveness (client, then server). After that, the app captures a selfie through the liveness flow and passes the result to your backend.
5. Face comparison (server). Next, your backend asks for a similarity score between the selfie and the card photo.
6. Decision (server). Finally, your rules combine every result into approve, reject, or review.

Running OCR before record validation, for one, saves users from typing. Similarly, running liveness before comparison stops you from paying to compare a photo of a photo. For background on which IDs to support, see our overview of national ID verification.

SDK vs Direct API: Which to Choose

Most providers offer both a mobile or web SDK and plain REST APIs. Still, the right choice depends on how much of the capture experience you want to own.

Factor	SDK	Direct API
Camera capture and guidance	Built in, tuned for ID cards and faces	You build it yourself
Liveness	Usually includes active and passive modes	Typically passive, from submitted images
Time to launch	Shorter	Longer
UI control	Limited to provider theming	Full control
App size	Adds a library to your build	No extra library
Best for	Consumer apps that need a fast, polished flow	Back-office review tools and batch checks

Many teams combine the two. They use the SDK on the client for capture and liveness, then call the APIs from the backend for OCR, record validation, and comparison. Above all, that split keeps API keys off the device.

Step-by-Step Integration and API Call Order

Once you know the flow, the build itself follows a predictable path.

1. Get credentials and test access. First, ask your provider for test keys and documentation for each service you plan to use.
2. Design your data model. Then create a verification record per user that stores each step’s status, result, and timestamp.
3. Build capture. Next, add the SDK or your own camera screens, including clear instructions in English and Filipino.
4. Proxy calls through your backend. Never call the provider directly from the app with a secret key.
5. Chain the checks. Call OCR, then record validation, then comparison, stopping early when a step fails hard.
6. Write decision rules. For instance, auto-approve when every check passes, send partial matches to review, and reject clear fraud signals.
7. Build the review screen. Finally, give reviewers the images, extracted fields, and each result in one view.

For Philippine IDs, Verihubs OCR Extraction reads local cards into structured fields, while Verihubs ID Verification validates PhilSys, LTO, SSS, and NBI details. So a single provider can cover both extraction and record checks for local IDs.

Handling Results, Errors, and Retries

The happy path is the easy part. In fact, most of the engineering effort goes into what happens when something does not pass.

Situation	Recommended handling
Blurry or cropped ID image	Reject on the client and ask for a new photo before upload
OCR misreads a field	Let the user correct it, but log the change and re-validate
Record not found	Allow one retry with corrected data, then route to review
Liveness fails	Offer a guided retry; repeated failures suggest a spoof attempt
Face match below threshold	Queue for a human reviewer; do not reject automatically
Timeout or provider error	Retry with backoff using the same request ID, then queue

Two habits prevent most production incidents. First, make every call idempotent, so a retried request does not charge twice or create duplicate records. Second, cap user retries, because unlimited attempts help fraudsters tune their spoofs.

Testing, Sandbox, and Going Live

Of course, testing an eKYC flow needs more than unit tests. In particular, you need real-world images from the devices your users carry.

• Test with real ID types. Cover PhilID, ePhilID printouts, driver’s licenses, UMID, and passports.
• Test on low-end phones. After all, entry-level Android devices and weak connections reveal capture problems early.
• Test spoof attempts. Try printed photos, screens, and recorded video to confirm liveness rejects them.
• Load test the backend. Otherwise, promotions and payday surges can overwhelm it within an hour.
• Launch in stages. Start with a small share of new users, compare results with your old process, then expand.

Before launch, also confirm your privacy notice and consent screen cover every check you run. For what that notice must include, see our breakdown of privacy rules for KYC.

Common Integration Mistakes

Teams that integrate eKYC for the first time tend to repeat a handful of errors.

• Calling the API from the device. Once exposed, keys get abused, and you lose control of the flow.
• Trusting client-side results. Instead, always confirm the final result on your server.
• Skipping liveness. Without it, a stolen ID photo plus a printed selfie can pass face comparison.
• Auto-rejecting borderline matches. Genuine users get locked out; route them to review instead.
• Storing images forever. Rather, keep only what your retention policy requires.
• No monitoring. Track completion, pass, and review rates per step, or problems stay invisible.

Most of these come from treating eKYC as a single feature rather than a pipeline. Meanwhile, our article on fintech onboarding shows how the pipeline fits the wider customer journey.

Frequently Asked Questions

How long does it take to integrate an eKYC API?

Timelines depend on scope. A team using an SDK for capture and standard APIs for checks can usually launch much faster than one building camera and liveness flows from scratch. Either way, plan extra time for testing on real devices.

Should I use an SDK or call the API directly?

Use an SDK when you want polished capture and active liveness quickly. Call APIs directly for server-side checks, back-office tools, or full UI control. Many apps use both.

Which Philippine IDs can an eKYC API verify?

Coverage varies by provider. Typically, common options include the PhilID, driver’s license, SSS, UMID, and passport. Ask each provider which records they validate against official sources and which they only read with OCR.

Where should eKYC API calls be made?

Make verification calls from your backend, never from the mobile app with a secret key. The app handles capture, while the server calls the provider and stores results.

What should happen when face matching fails?

Offer one guided retry, then route the case to manual review. Otherwise, auto-rejecting borderline scores locks out genuine users, especially those with older ID photos.

Build the Pipeline, Not Just the Feature

An eKYC API integration succeeds when every step has a clear order, owner, and fallback. So capture on the client, verify on the server, chain OCR, record validation, liveness, and comparison, then decide with rules that send edge cases to people. Test with real Philippine IDs and real phones, and the flow will hold up when sign-ups spike.

Scoping an eKYC integration for Philippine users? Ask Verihubs for API documentation and test access.