Mtumiaji anaandika namba yake ya kitambulisho cha kitaifa. Didit inaiangalia dhidi ya database ya serikali iliyoitoa katika nchi 36, na inalinganisha selfie yao na picha ya usajili pale ambapo usajili unarudisha picha.
Inaaminika na mashirika 2,000+ duniani kote.
Upatikanaji na bei hutoka kwenye orodha ya njia za uzalishaji, si kutoka ukurasa huu. Nchi huwaka hapa mara tu inapoweza kuwashwa ndani ya mtiririko wako wa kazi; bei ni USD kwa jaribio lililojibiwa.
Inapatikana leo
Kuanzia Argentina hadi Afrika Kusini, kila nchi kwenye orodha inapatikana na bei yake maalum ya nchi karibu nayo. Argentina, Nigeria, Panama na Afrika Kusini hurejesha picha ya rejista, kwa hivyo nchi hizo nne pia huendesha selfie, passive liveness na face match ndani ya utafutaji mmoja.
Washa utafutaji kwa nchi zinazounga mkono. Chagua kinachotokea kwenye mechi isiyo kamili, kwenye kutolingana, na wakati rejista inakaa kimya. Weka idadi ya majaribio anayopata mtumiaji. Hakuna code inayohitajika.
Moja kwa moja kutoka kwenye katalogi ya mbinu
Rejista za moja kwa moja
Rudisha picha
Picha za hati zinazohitajika
Kila nchi iliyoorodheshwa inapatikana moja kwa moja. Kuingia kwa dashi, ikiwa kutatokea hapa, kumo kwenye katalogi lakini bado hakujawashwa.
Department of Home Affairs
Uthibitishaji wa umbizo hufanyika kabla ya chochote kuondoka kwenye kifaa. Namba iliyochapwa vibaya haifiki kamwe kwenye rejista na haitozwi kamwe.
Ambapo rejista inarudisha picha
Swichi moja kwa kila matokeo
Kwenye kipindi
Lebo za uhakikisho ni kwa ajili ya wakaguzi wako. Mtumiaji wa mwisho hazioni kamwe, jina la chanzo, au bei.
Afrika Kusini, USD kwa kila jaribio lililojibiwa
$2.20Kila kiwango ni bei ya rejareja ya umma ya USD na inajumuisha selfie, liveness na utambuzi wa uso ambapo rejista inarudisha picha. Upigaji picha wa hati unatozwa tu wakati mtumiaji anarudi nyuma.
$ curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: <your-api-key>" \
-H "Content-Type: application/json" \
-d '{
"workflow_id": "wf_id_lookup",
"vendor_data": "user_42"
}'{ "url": "https://verify.didit.me/..." }const crypto = require("crypto");
// X-Signature-V2 signs canonical JSON: keys sorted as strings, compact,
// Unicode preserved. Emit the sorted entries directly - rebuilding an object
// would reorder integer-like keys ("10", "2"). Never hash req.rawBody.
const canonical = (v) =>
Array.isArray(v) ? "[" + v.map(canonical).join(",") + "]"
: v && typeof v === "object"
? "{" + Object.keys(v).sort()
.map((k) => JSON.stringify(k) + ":" + canonical(v[k])).join(",") + "}"
: JSON.stringify(v);
app.post("/webhooks/didit", express.json(), (req, res) => {
// Freshness: the signed body timestamp (refreshed on retry) must be recent
// and X-Timestamp must agree - the header alone is unsigned and replayable.
const ts = Number(req.body?.timestamp);
if (!ts || String(ts) !== req.headers["x-timestamp"] ||
Math.abs(Date.now() / 1000 - ts) > 300) return res.sendStatus(401);
const expected = crypto.createHmac("sha256", SECRET)
.update(canonical(req.body), "utf8").digest("hex");
const sig = String(req.headers["x-signature-v2"] ?? "");
const valid = sig.length === expected.length &&
crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected));
if (!valid) return res.sendStatus(401);
const { status, decision } = req.body;
// One entry per ID Verification node; pick yours by node_id when you run several.
const [idv] = decision?.id_verifications ?? [];
// idv.verification_method: "document" | "id_lookup" | "wallet"
res.sendStatus(200);
});{ "verification_method": "id_lookup", "assurance": "data_match" }# Didit non-document verification — integrate in 5 minutes
You are adding non-document identity verification to my_stack. The user types a
national ID number plus a few personal details, and Didit checks them against
the government database that issued the number. Every URL, header, and enum
value below is canonical — do not paraphrase or "improve" them.
## 1. Provision an account
- Sign up: https://business.didit.me (no credit card required).
- Grab the API key for your application from the console.
## 2. Read the methods catalog first
Availability is server-driven per country. Never hard-code a country list.
The catalog is not a public REST endpoint. Read it one of two ways:
- Business Console (signed in): your application -> ID Verification ->
Countries tab. https://docs.didit.me/console/id-verification-methods
- Didit MCP server tool didit_workflow_get_id_verification_methods_catalog,
authenticated with the same x-api-key; pass country (ISO 3166-1 alpha-3)
to narrow it to one country. https://docs.didit.me/integration/mcp/tools
- Public mirror of the coverage table (no auth, read-only):
https://docs.didit.me/core-technology/id-verification/verification-methods#coverage
The catalog tells you, per ISO 3166-1 alpha-3 country code:
- whether id_lookup is available
- the source label and the public USD rate per answered attempt (36 countries
are live at the time of this prompt, from Argentina to South Africa)
- the exact request fields to ask the user for, with their format rules
- the response fields that come back, and which of them are optional
## 3. Create a workflow with the ID Verification (OCR) feature
POST https://verification.didit.me/v3/workflows/
-H "x-api-key: <your-api-key>"
-H "Content-Type: application/json"
The ID Verification feature's enum value is OCR (UPPERCASE — strict enum;
there is no ID_VERIFICATION alias and the API rejects it). Non-document
lookup is its id_lookup method, configured per country under config.methods
on that same feature entry, in the same request. Keys are ISO 3166-1 alpha-3.
An omitted country, or an omitted methods key, means document only.
{
"workflow_label": "Non-document onboarding",
"features": [
{
"feature": "OCR",
"config": {
"methods": {
"ZAF": {
"document": { "enabled": true },
"id_lookup": {
"enabled": true,
"max_attempts": 1,
"skip_liveness_and_face_match": false,
"on_partial_match": "fallback_to_document",
"on_no_match": "fallback_to_document",
"on_provider_error": "fallback_to_document",
"response_fields": ["gender", "citizenship", "registry_portrait"]
}
}
}
}
}
]
}
Response: the workflow uuid — use it as workflow_id in step 4.
Rules that the API enforces:
- every fallback value is either fallback_to_document or decline
- max_attempts is an integer from 1 to 5, default 1
- skip_liveness_and_face_match is only accepted where the source returns a
portrait; elsewhere it is rejected
- response_fields lists the OPTIONAL fields you want stored. Required fields
are always stored and cannot be removed
- a country whose id_lookup the catalog does not mark available is rejected
- a country with no method enabled is rejected at publish time
## 4. Create a session
POST https://verification.didit.me/v3/session/
-H "x-api-key: <your-api-key>"
-H "Content-Type: application/json"
-d '{ "workflow_id": "<id from step 3>", "vendor_data": "<your user id>" }'
Response: 201 with url (the hosted verification link), session_token and
session_id. Redirect the user to url, or open it in the SDK. The field is
named url — there is no session_url and no verification_url.
Didit asks the user for the request fields in plain language, runs the
client-side format check, then queries the registry.
Where the registry returns a portrait (Argentina, Nigeria, Panama, South
Africa), Didit also takes a selfie, runs passive liveness on it, and
face-matches it to that portrait. All of it is inside the lookup price.
## 5. Webhooks
Register a destination (console -> API & Webhooks, or
POST https://verification.didit.me/v3/webhook/destinations/ with
webhook_version "v3" and subscribed_events ["status.updated"]) and store the
secret_shared_key it returns. Verify every delivery:
Header: X-Signature-V2 (NOT X-Signature, NOT X-Signature-Simple)
Algorithm: HMAC-SHA256, hex digest, over the CANONICAL JSON of the payload:
parse the body, sort keys recursively, serialise compact with
Unicode preserved and whole-valued floats as integers. Do NOT
hash the raw request bytes — that is the v1 X-Signature
algorithm and fails for V2 whenever whitespace or key order
differs from the canonical form.
Freshness: the signed body field timestamp is the dispatch time (Unix
seconds, refreshed on every retry). Reject when
abs(now - timestamp) > 300 seconds, and reject when the
X-Timestamp header does not equal it. The header is not
covered by the signature, so it must never be the only replay
check: a captured delivery replays with just that header
refreshed.
Compare: constant-time (crypto.timingSafeEqual)
Reference handler (Express) — use it as written:
const crypto = require("crypto");
// X-Signature-V2 signs canonical JSON: keys sorted as strings, compact,
// Unicode preserved. Emit the sorted entries directly - rebuilding an object
// would reorder integer-like keys ("10", "2"). Never hash req.rawBody.
const canonical = (v) =>
Array.isArray(v) ? "[" + v.map(canonical).join(",") + "]"
: v && typeof v === "object"
? "{" + Object.keys(v).sort()
.map((k) => JSON.stringify(k) + ":" + canonical(v[k])).join(",") + "}"
: JSON.stringify(v);
app.post("/webhooks/didit", express.json(), (req, res) => {
// Freshness: the signed body timestamp (refreshed on retry) must be recent
// and X-Timestamp must agree - the header alone is unsigned and replayable.
const ts = Number(req.body?.timestamp);
if (!ts || String(ts) !== req.headers["x-timestamp"] ||
Math.abs(Date.now() / 1000 - ts) > 300) return res.sendStatus(401);
const expected = crypto.createHmac("sha256", SECRET)
.update(canonical(req.body), "utf8").digest("hex");
const sig = String(req.headers["x-signature-v2"] ?? "");
const valid = sig.length === expected.length &&
crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected));
if (!valid) return res.sendStatus(401);
const { status, decision } = req.body;
// One entry per ID Verification node; pick yours by node_id when you run several.
const [idv] = decision?.id_verifications ?? [];
// idv.verification_method: "document" | "id_lookup" | "wallet"
res.sendStatus(200);
});
Body fields you will use: session_id, status, webhook_type, workflow_id,
vendor_data, decision.
Status values: Approved, Declined, In Review, In Progress, Not Started,
Abandoned.
## 6. Reading the result
The decision is the V3 shape: every feature result is a plural array with one
entry per workflow node. ID Verification results live in
decision.id_verifications[] — there is no singular decision.kyc (that is the
V2 shape) and no decision.id_verification. Select your entry by node_id (the
id of your ID Verification node in the workflow graph); with a single ID step,
take index 0. Each entry carries, next to the document fields:
verification_method "document" | "id_lookup" | "wallet"
assurance "documentary" | "data_match" | "cryptographic"
id_lookup source label, checked_at, attempts, outcome, one
comparison row per field with match / partial /
no_match, and the registry portrait reference when
there is one; null on document entries
fallback_from { method, reason, action } when the session fell
back to document capture or was declined; else null
A non-document entry that succeeds is assurance data_match, never
documentary. The fallbacks only govern unsuccessful lookups (partial match,
no match, provider error): a lookup that matches is accepted as the ID result
and never reaches them, so switching them to decline does not add documentary
evidence. If your risk policy needs documentary assurance for a segment, do
not enable id_lookup for that segment's country: configure
"document": { "enabled": true } alone (omit the id_lookup key, or set its
enabled to false) and route that segment to a workflow of its own when other
users may keep the lookup. As a final guard, treat any id_verifications[]
entry whose assurance is not documentary as failing that policy.
Field-by-field reference: https://docs.didit.me/reference/data-models#id-verification
## 7. Billing — what actually bills
- a registry that answered bills the lookup. Match, partial match and no
match all count as answered
- document capture bills on top when the user falls back
- a source that never answered is not billed
- a number that fails the client-side format check never reaches the registry
and is neither counted nor billed
## 8. Hard rules — do not change
- base URL for v3 endpoints: verification.didit.me
- auth header: x-api-key (lowercase, hyphenated)
- webhook headers: X-Signature-V2 plus X-Timestamp; canonical JSON, never
raw bytes; freshness from the signed body timestamp
- feature enum: OCR (uppercase) — the ID Verification feature; per-country
methods go under its config.methods
- method keys: document, id_lookup, wallet (lowercase, snake_case)
- country keys: ISO 3166-1 alpha-3, uppercase
- result path: decision.id_verifications[] (array), never decision.kyc
## 9. Verify your integration
- run one session per configured country in sandbox
- assert the id_verifications[] entry for your node has verification_method
id_lookup on the happy path
- force a no-match and assert the fallback you configured actually fires
- for a segment that needs documentary assurance, run a lookup that matches
against that segment's workflow and assert its entry has
verification_method document and assurance documentary
- assert your webhook accepts a correctly signed payload with reordered
keys, whitespace and integer-like metadata keys ("10" before "2"), and
rejects a wrong X-Signature-V2, a payload whose signed timestamp is older
than 300 seconds, and that same stale payload with only the X-Timestamp
header refreshed
Docs: https://docs.didit.me/integration/integration-prompt
Kwa ajili ya kuunda, kujaribu, na watumiaji wako wa kwanza.
Moduli 25+, bei wazi. Punguzo la kiotomatiki kwa wingi.
Kwa kiasi kikubwa na programu zilizodhibitiwa.
Punguzo la wingi hutumika kiotomatiki kadri matumizi yanavyoongezeka — hakuna mazungumzo, hakuna simu ya mauzo.
Didit ni miundombinu ya utambulisho na udanganyifu, jukwaa ambalo tulitamani lingekuwepo tulipokuwa tukijenga bidhaa sisi wenyewe: wazi, rahisi kubadilika, na rafiki kwa wasanidi, ili lifanye kazi kama sehemu halisi ya stack yako badala ya black box unayounganisha.
API moja inashughulikia kuthibitisha watu (KYC, know your customer), kuthibitisha biashara (KYB, know your business), kuchunguza crypto wallets (KYT, know your transaction), na kufuatilia miamala kwa wakati halisi, kwenye stack iliyojengwa kuwa:
Msingi wake: aina 14,000+ za hati katika lugha 48+, vyanzo vya data 1,000+, na ishara za udanganyifu 200+ kwenye kila session. Miundombinu ya Didit inajifunza kwa nguvu kutoka kila session na inaboresha kila siku.
Mtumiaji anaandika namba yake ya kitambulisho cha kitaifa pamoja na maelezo machache ya kibinafsi, na Didit inayaangalia dhidi ya database ya serikali iliyotoa namba hiyo — hakuna picha ya hati popote kwenye mchakato.
Pale ambapo rejista inarudisha picha ya mtu, Didit pia inapiga selfie, inafanya passive liveness juu yake, na kuilinganisha na picha hiyo. Hiyo imejumuishwa kwenye bei ya utafutaji, haitozwi ziada.
Sio bidhaa tofauti. Ni njia moja ndani ya ID_VERIFICATION, inayowashwa kwa kila nchi kando ya ukamataji wa hati na digital ID wallets.
Nchi thelathini na sita zinajibu leo, kila moja kupitia chombo cha serikali kilichotoa namba hiyo — miongoni mwao Argentina (RENAPER), Brazil (Receita Federal), Colombia (Registraduría), India (UIDAI), Kenya (IPRS), Mexico (RENAPO), Nigeria (NIMC / NIBSS), Peru (RENIEC), Afrika Kusini (Department of Home Affairs) na Uingereza na Marekani kupitia rekodi za credit-bureau na huduma za kifedha.
Argentina, Nigeria, Panama na Afrika Kusini zinarudisha picha ya rejista, hivyo nne hizo pia zinajumuisha selfie, passive liveness na face match.
Upatikanaji hutolewa na orodha ya methods, hivyo workflow yako inaona nchi siku ambayo iko tayari. Orodha kamili na viwango iko kwenye /pricing. Ukamataji wa hati bado unashughulikia nchi 220+ — angalia /supported-documents.
Mchakato mzima kwa kawaida huchukua chini ya sekunde 30 kuanzia mwanzo hadi mwisho — hiyo ndiyo kasi zaidi sokoni. Watoa huduma wa zamani kwa kawaida huchukua zaidi ya sekunde 90 kwa mchakato huo huo.
Kuandika namba ya kitambulisho ni haraka kuliko kupiga picha hati, hivyo utafutaji usio wa hati kwa kawaida ndiyo njia ya haraka zaidi mtumiaji anaweza kuchukua. Kwenye back end Didit inarudisha matokeo kwa chini ya sekunde mbili kwa p99.
Namba peke yake haitoshi kamwe.
Pale ambapo rejista inarudisha picha ya mtu, Didit inapiga selfie, inafanya passive liveness juu yake ili kuthibitisha kuwa binadamu halisi yupo, na face-matches na picha ya rejista. Namba iliyoibiwa na uso usio sahihi haipiti.
Pale ambapo rejista hairudishi picha, utafutaji unathibitisha data inalingana na rekodi lakini si kwamba mtu yupo. Kwa nchi hizo, weka fallback ya ukamataji wa hati ikiwa imewashwa, au unganisha utafutaji na liveness katika workflow moja.
Unaamua, kwa kila nchi, kwa swichi tatu tofauti: partial match, no match, na no response from the provider. Kila moja ama inarudi kwenye ukamataji wa hati au inakataa session.
Unaweka pia idadi ya majaribio anayopata mtumiaji kabla ya fallback kuwaka — 1 hadi 5, default 1.
Matokeo yanaandika kilichotokea: njia iliyotumika, njia iliyorudiwa kutoka, na sababu. Hakuna kinachomezwa kimya kimya.
Utafutaji unatozwa kwa kila nchi, kwa sababu kila rejista inatoza tofauti — kutoka $0.05 katika Jamhuri ya Dominika hadi $4.30 nchini Singapore, huku rejista nyingi za Amerika Kusini zikiwa $0.20. Kila kiwango ni cha umma kwenye /pricing. Rejista iliyojibu inatoza utafutaji — match, partial match na no match zote huhesabiwa kama zimejibiwa.
Pale ambapo rejista inarudisha picha, selfie, passive liveness na face match ziko ndani ya kiwango hicho, si juu yake. Ukamataji wa hati unatoza $0.15 tu wakati mtumiaji anarudi nyuma, na uthibitishaji 500 wa kwanza wa hati kila mwezi ni bure, milele.
Rejista ambayo haijawahi kujibu haitozwi. Namba inayoshindwa ukaguzi wa format haifiki kwenye rejista na haihesabiwi wala kutozwa.
Imesimbwa kwa njia fiche wakati wa usafirishaji na wakati imehifadhiwa, katika eneo unalochagua, chini ya SOC 2 Type 1 na Type 2, ISO 27001 na GDPR.
Kila utafutaji unafanywa chini ya mfumo wa faragha wa ndani — POPIA nchini Afrika Kusini, NDPR nchini Nigeria, LGPD nchini Brazil, UK GDPR nchini Uingereza, GLBA permissible purpose nchini Marekani — na Didit inaomba ridhaa ya mtumiaji kabla ya kuuliza rejista inayohitaji.
Sehemu za majibu za hiari zinaweza kutochaguliwa ili zisihifadhiwe kabisa. Sehemu zinazohitajika huhifadhiwa kila wakati. Maelezo kamili kwenye /security-compliance.
Didit inatumika na kampuni 2,000+ katika tasnia zinazodhibitiwa — fintech, benki, iGaming, crypto, masoko, huduma za afya na serikali.
Utafutaji usio wa hati unarudisha uhakikisho wa data match badala ya uhakikisho wa documentary. Pale ambapo mdhibiti wako anahitaji hati, weka ukamataji wa hati kama fallback, au weka nchi kukataa badala yake. Kiwango cha uhakikisho kiko kwenye kila session, hivyo mkaguzi anaweza kuona ni ushahidi gani hasa uliunga mkono kila uamuzi.
Memos kwenye /security-compliance.
Dakika chache, kwa njia tatu.
Anza kwenye business.didit.me, au soma docs.didit.me/integration/integration-prompt.
API moja kwa KYC, KYB, Ufuatiliaji wa Miamala, na Uchunguzi wa Wallet. Unganisha ndani ya dakika 5.