A demo has one happy path. Production has expired documents, bad lighting, a country you had not planned for, and an agent on the phone with a customer who needs an answer now.
What an identity verification API has to return
An identity verification API takes a document, a face or a name and returns an assessment of it. The hard part is not the call. It is what comes back: an answer detailed enough that your own rules can act on it, traceable enough that an auditor can follow it, and fast enough that the customer is still there when it arrives.
The integration is designed around that gap rather than around the demo.
One API, not a second integration
Document verification, biometrics and open-source intelligence share the same base URL, the same bearer token and the same JSON shape. Adding a capability means calling another endpoint group, not starting a new project.
- REST over HTTPS, with the same authentication everywhere.
- Synchronous answers for the checks that are fast, callbacks for the ones that are not.
- Every response carries the identifier you will use to find it again in the audit record.
It runs where your systems already run
Thin clients, virtual desktops and bespoke core systems are the normal case, not the exception. Deployment is built to sit beside what you have rather than ask you to replace it.
If the workflow requires new hardware at every counter, it is not an integration. It is a migration wearing one.
The report is the contract
What comes back is not a boolean. It is the outcome, the confidence, the checks that ran and the ones that could not, so your own rules can decide what a borderline case means for your risk appetite.
Two institutions reading the same report will reasonably draw different lines. The report exists to let them, instead of hiding the decision inside our threshold.
What we expect from you
A test environment, a list of the document types and countries you actually see, and someone who can say what your operations team does today when a check comes back uncertain. That last one shapes the integration more than anything technical.
Designing for the uncertain case
Every verdict is accept or escalate. The accepted cases are easy to wire: the journey continues. The escalated ones are where integrations succeed or fail, because they need a place to land, a person to read them and the full record of what ran, attached to the case rather than lost in a log.
The best integrations decide that path before the first line of code: who sees an escalation, how quickly, and what they are allowed to decide. The API gives them the material; the workflow is theirs.
What changes at the counter
The measure of a good integration is not the API call. It is the agent's shift. A check that took a trained agent 3 to 5 minutes comes back in under 7 seconds, with nothing to type, and the agent's attention goes back to the customer in front of them.
- One base URL and one bearer token for documents, biometrics and open-source intelligence.
- An outcome, a confidence and the list of checks, never a bare yes or no.
- An identifier on every response that leads back to the audit record.
- Deployment beside your existing systems, not in place of them.
Questions teams ask before integrating
Do documents, biometrics and OSINT need separate integrations?
No. They share one base URL, one bearer token and one JSON shape. Adding a capability means calling another group of endpoints on the integration you already have.
Are the answers synchronous?
The fast checks answer synchronously. The longer ones answer through a callback, so your system is not holding a connection open while they run.
Does it work with thin clients and virtual desktops?
Yes. Deployment is built to sit beside existing systems, including thin clients, virtual desktops and bespoke core systems, rather than to replace them.
What should we prepare?
A test environment, the list of document types and countries you actually see, and a clear owner for escalated cases: who reads them, how fast, and what they are allowed to decide.