Do we have to build the verification screens?

No. Identiko hosts them. Your app sends the customer to a secure link, and the flow runs your checks with your logo and colours, using the camera only. When they finish, they return to a page in your app that you choose.

Which programming languages does it work with?

Any language that can make a web request and read JSON. There’s nothing to install.

How do we know a result really came from Identiko?

Every message is signed with a secret only you and Identiko know (HMAC-SHA256). Your server re-creates the signature, compares the two, and rejects anything more than 5 minutes old.

What if our server is down when a result is ready?

Identiko tries again after 30 seconds, 5 minutes, 30 minutes, 2 hours, 6 hours, 12 hours and 24 hours, and stops as soon as your server answers. If every attempt fails, it warns another address you choose.

Could a request be sent twice by mistake?

It can be sent twice without creating two records. Each request can carry an Idempotency-Key; for 24 hours, a repeat gets the first answer back.

Do our developers see customers’ documents?

They don’t need to. With a role that leaves applicant data out, a developer can build and run the integration without seeing anyone’s documents or face.

Will future changes break our integration?

Each place you send results to is set up against an API version, so a new kind of update can never surprise code that’s already running.

Can we get the documents and selfies?

Yes. Your app can read a verification’s extracted data, the result of each check, and signed links to the captured files. The links expire.

Developers

Your app asks. Identiko answers.

Your app asks Identiko to verify someone. They complete it on their phone, in a flow with your branding, and the signed result comes straight back to your app.

See how it works Book a demo

No camera screens to build
Works with any programming language
Results signed, and resent for about a day

Your appIdentiko

Your app

Please verify our new customer, Layla Haddad, with our onboarding flow.

POST /verifications
{ "subject_id": "01a0142b-…",
  "workflow_id": "01a0141f-…",
  "channel": "hosted" }

Identiko

Done. Here’s her secure link. It works until 09:24.

hosted.identiko.io/v/8Kq2…

201 Created
{ "hosted_url": "https://hosted.identiko.io/v/8Kq2…",
  "expires_at": "2026-10-02T09:24:03+00:00" }

Meanwhile
Layla opens the link on her phone, scans her passport and takes a selfie.
```
# the hosted flow: document and face,
# camera only, under your brand
```

Identiko

Layla is verified. Her record and the evidence are in your console.

Signed by Identiko

POST /webhooks/identiko
X-Identiko-Event: verifications.approved
X-Identiko-Signature: t=1790847077,v1=6f8b…

Your app
Got it, thanks.
```
200 OK
```

How it works

Three steps, and only one needs your customer.

This is everything that happens when your product verifies someone. Your team writes the first and the last step; Identiko runs the middle.

Step 1

Your app asks

Your app tells Identiko who to verify and which of your flows to use. Identiko replies with a secure link for that person.

For developersPOST /identitiesPOST /verifications
Step 2

Your customer verifies

They open the link on their phone, scan their document and take a selfie. The flow runs your checks, with your logo and colours.

For developershosted_urlredirect_success_url
Step 3

You get the answer

Identiko sends the result to your app the moment it’s ready, signed so you know it’s real. The full record stays in your console.

For developersverifications.approvedGET /verifications/{id}

Built in

Hard to get wrong, by design.

Six things the API takes care of, so an integration stays safe and predictable. The technical detail sits under each one.

No duplicates, even on a retry
If a request gets lost and your app sends it again, Identiko recognises it and returns the first answer instead of creating a second record.

Under the hoodIdempotency-Key, replayed for 24 hours
One key, only the access it needs
Each integration gets its own key, limited to what it should do, with an optional expiry date.

Under the hoodX-API-KEY, scopes, GET /api-keys/whoami
Your developers never see your customers
A developer can build and run the whole integration without access to anyone’s documents or face.

Under the hoodRoles that leave applicant data out
Keys can’t promote themselves
A key can’t create other keys or add places to send results. Those need a signed-in owner or admin.

Under the hoodKeys can’t mint keys or register endpoints
The same shape, every time
Every answer comes back in the same format, so code written once keeps working as you use more of the API.

Under the hooddata, meta and links, paged with page and per_page
Clear about busy moments
If your app sends too much at once, Identiko says exactly how long to wait before trying again.

Under the hood429 with Retry-After, in the header and the body

Webhooks

We tell you the moment it’s done.

When a verification finishes, Identiko sends the result straight to your server, signed so you know it came from us. If your server is down, we keep trying for about a day.

The message your server gets

Verification approvedSigned

From: Identiko, signedX-Identiko-Signature
About: Verification approvedX-Identiko-Event
Message number: The same if we resend itX-Identiko-Event-Id
Attempt: New on every resendX-Identiko-Delivery

How your server knows it’s real

Check the timeReject any message more than 5 minutes old.timestamp within 300 s
Re-create the signatureSign the message with your own secret.HMAC-SHA256 over "{t}.{raw body}"
Compare the twoIf they match, it came from Identiko.constant-time compare

If your server is down

Pick when it comes back, and see what Identiko does.

NowAttempt 1No answer
30 sAttempt 2Delivered
5 minAttempt 3Not needed
30 minAttempt 4Not needed
2 hAttempt 5Not needed
6 hAttempt 6Not needed
12 hAttempt 7Not needed
24 hAttempt 8Not needed
thenWe warn youwebhook.failed

The second attempt, 30 seconds after the first, got through, so Identiko stopped trying. Both attempts carried the same message number, so your server can ignore a repeat.

Updates

35 things Identiko can tell your systems.

Each of your systems subscribes to the updates it cares about, and nothing else. These are the ones most teams start with.

Verifications11
- Startedverifications.started
- Needs a reviewverifications.requires_review
- Approvedverifications.approved
- Rejectedverifications.rejected
and 7 more
Identities7
- Createdidentities.created
- Updatedidentities.updated
- Flaggedidentities.flagged
- Archivedidentities.archived
and 3 more
Blocklist & Bio-Intel6
- Blocklist matchblocklist.entry_hit
- Face search finishedbio_intel.session.completed
- Face search flaggedbio_intel.session.flagged
and 3 more
Workspace11
- Workflow publishedworkflows.published
- API key rotatedapi_key.rotated
- Balance running lowbilling.wallet_low
- A webhook failedwebhook.failed
and 7 more

Every update, field and response is in the developer guide. Identities, verifications, workflows, webhooks and API keys.

Read the developer guide

Questions

Questions, answered plainly.

For your product team and your developers.

Read the developer guide

Do we have to build the verification screens?
No. Identiko hosts them. Your app sends the customer to a secure link, and the flow runs your checks with your logo and colours, using the camera only. When they finish, they return to a page in your app that you choose.
Which programming languages does it work with?
Any language that can make a web request and read JSON. There’s nothing to install.
How do we know a result really came from Identiko?
Every message is signed with a secret only you and Identiko know (HMAC-SHA256). Your server re-creates the signature, compares the two, and rejects anything more than 5 minutes old.
What if our server is down when a result is ready?
Identiko tries again after 30 seconds, 5 minutes, 30 minutes, 2 hours, 6 hours, 12 hours and 24 hours, and stops as soon as your server answers. If every attempt fails, it warns another address you choose.
Could a request be sent twice by mistake?
It can be sent twice without creating two records. Each request can carry an Idempotency-Key; for 24 hours, a repeat gets the first answer back.
Do our developers see customers’ documents?
They don’t need to. With a role that leaves applicant data out, a developer can build and run the integration without seeing anyone’s documents or face.
Will future changes break our integration?
Each place you send results to is set up against an API version, so a new kind of update can never surprise code that’s already running.
Can we get the documents and selfies?
Yes. Your app can read a verification’s extracted data, the result of each check, and signed links to the captured files. The links expire.
Where’s the full technical reference?
In the developer guide: identities, verifications, workflows, webhooks and API keys, with every field and response.

Get started

Run your first verification today.

Start free with credit on us and every check included, or book a demo for your institution.

Your app asks. Identiko answers.

Three steps, and only one needs your customer.

Your app asks

Your customer verifies

You get the answer

Hard to get wrong, by design.

No duplicates, even on a retry

One key, only the access it needs

Your developers never see your customers

Keys can’t promote themselves

The same shape, every time

Clear about busy moments