Lumaktaw sa pangunahing nilalaman
ShieldID

API reference

Ang API reference ng identity verification.

Bawat endpoint na maaari mong tawagin, bawat field na makikita mo sa tugon, at kung ano ang gagawin sa isang webhook kapag dumating ito. Para sa eksaktong uri ng field, ituring na source of truth ang live OpenAPI document sa /docs sa sarili mong API origin — ito namang pahinang ito ay bersyong madaling maintindihan.

Base URL at mga environment

Isang base URL. Dalawang environment.

Sa iisang host napupunta ang bawat request. Ang API key na ipinapadala mo ang ganap na nagpapasya kung aling environment ka.

Ang bawat request sa reference na ito ay nakabatay sa dalawang bagay na ito.
Base URL (ang dokumentasyong ito)https://api.shieldid.ca — illustrative; your production API origin is published together with your API keys.
Auth headerX-Api-Key: <your key>, sa bawat request maliban sa dalawang public endpoint na nakasaad sa ibaba.
Prefix ng sandbox keyvk_sand_… — ang mga session na ginawa gamit ang key na ito ay may tatak na environment: "sandbox" at hindi kailanman sinisingil.
Prefix ng production keyvk_live_… — ang parehong mga request, sinisingil ayon sa iyong plan.
Content typeapplication/json sa bawat request body at response.

Mga Endpoint

Ang buong v1 surface.

Anim na JSON endpoint, kasama ang isang hosted page at isang public credential check na hindi JSON — i-link mo lang ang mga ito.

Mga JSON endpoint sa ilalim ng /v1.
EndpointAuthWhat it does
POST /v1/sessionsX-Api-KeyGumawa ng verification session. Nangangailangan ng return_url at webhook_url. Nagbabalik ng session_id, verification_url at status: "PENDING".
GET /v1/sessions/{id}X-Api-KeyStatus at mga pangunahing field para sa isang session: status, confidence, environment.
GET /v1/sessions/{id}/resultX-Api-KeyAng buong resulta kapag ang session ay umabot na sa VERIFIED o FAILED: person, mga verdict kada check, confidence, verified_until.
DELETE /v1/sessions/{id}X-Api-KeyKanselahin ang session na PENDING o IN_PROGRESS pa. Ang session na nasa VERIFIED, FAILED o EXPIRED na ay hindi na maaaring kanselahin.
GET /v1/credentials/{token}None — publicTingnan kung kasalukuyang valid ang isang verified credential. Hindi kailangan ng API key, kaya puwede itong tawagin mula sa browser. Tandaan: ang kasalukuyang response ay may kasamang pangalan ng na-verify na tao at document type/country, hindi lang valid/invalid flag — huwag ibigay ang link na ito sa third party na ayaw mong makakita niyon.
GET /v1/pricing/{country}X-Api-KeyPresyo kada bansa para sa isang two-letter na ISO 3166-1 country code.
Mga pahinang ili-link ninyo, hindi JSON na ipa-parse.
/v/{session_id}Ang hosted verification page — ang verification_url na ibinabalik ng isang session. Sa desktop, nagpapakita ito ng QR code; kapag na-scan, ibibigay nito sa telepono ng applicant ang parehong link para makuhanan ang kanilang dokumento at selfie.
/c/{session_id}Isang public at unauthenticated na credential-check page para sa isang verified session. Tandaan: ang kasalukuyang response ay may kasamang pangalan ng na-verify na tao at document type/country, hindi lang valid/invalid flag — huwag ibigay ang link na ito sa third party na ayaw mong makakita niyon.
/docsAng live at interactive na OpenAPI reference para sa API origin ng iyong account.

Paggawa ng session

POST /v1/sessions, mula simula hanggang dulo.

Ang request, at eksakto kung ano ang isinasagot.

bash
curl -X POST https://api.shieldid.ca/v1/sessions \
  -H "X-Api-Key: vk_sand_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "return_url": "https://yourapp.example/verified",
    "webhook_url": "https://yourapp.example/hooks/shieldid",
    "expected_name": "Jordan Smith",
    "locale": "en",
    "metadata": { "application_id": "app_9182" }
  }'

POST /v1/sessions — mga request field.
return_urlstring, kinakailangan — Kung saan ibabalik ang applicant pagkatapos nilang matapos. Dapat ay http o https.
webhook_urlstring, kinakailangan — Kung saan ihahatid ang signed na resulta. Tingnan ang Webhooks sa ibaba.
expected_namestring, kinakailangan — Ang pangalang inaasahan mo sa dokumento, ginagamit para i-cross-check kung ano talaga ang nakasulat sa ID.
expected_dob / expected_addressstring, opsyonal — Kino-cross-check sa dokumento kapag ibinigay; hindi kinakailangan para magpatakbo ng verification.
localestring, opsyonal — "en" o "fr". Itinatakda ang wika ng hosted page na nakikita ng applicant.
metadataobject, opsyonal — Sarili mong reference data — application id, tenant id, anumang gusto mong ibalik nang hindi nababago sa resulta at sa webhook.

Ang resulta

GET /v1/sessions/{id}/result — hugis ng response.

Ang parehong hugis ang inihahatid sa webhook payload, kaya bihira mo nang kailangang mag-poll sa endpoint na ito.

Mga top-level na field.
session_idAng id na ginawa mo.
statusPENDING, IN_PROGRESS, VERIFIED, FAILED o EXPIRED.
environment"sandbox" o "production", ayon sa key na gumawa ng session.
personAng mga field na nabasa mula sa dokumento: pangalan, petsa ng kapanganakan, uri ng dokumento, bansa at hurisdiksyon ng dokumento, address.
checksIsang verdict bawat check — tingnan sa ibaba. Hindi kailanman isang malabong score.
confidenceIisang kabuuang figure para sa beripikasyon. Iniuulat pa rin nang hiwalay ang mga indibidwal na check, kasama ang face match, laban sa nakatakdang decision line — hindi pinapalitan ng field na ito ang mga iyon.
verified_untilGaano katagal itinuturing na kasalukuyan ang resulta, sa isang VERIFIED na session.
failure_reasonItinatakda sa isang FAILED na session — halimbawa FACE_MATCH_BELOW_THRESHOLD o CANCELLED_BY_API. null kung hindi.
metadataAnumang ipinadala mo noong ginawa mo ang session, nang walang pagbabago.
json
{
  "session_id": "ses_9f2c1a",
  "status": "VERIFIED",
  "environment": "sandbox",
  "person": {
    "name": "Jordan Smith",
    "dob": "1994-03-11",
    "document_type": "drivers_licence",
    "document_country": "CA",
    "document_jurisdiction": "ON"
  },
  "checks": {
    "document": "PASS",
    "liveness": "PASS",
    "antispoof": "PASS",
    "face_match": "PASS"
  },
  "confidence": 88,
  "verified_until": "2027-03-11T00:00:00Z",
  "failure_reason": null,
  "metadata": { "application_id": "app_9182" }
}

Add-onAng checks.document, checks.liveness, checks.antispoof at checks.face_match ay nagreresulta sa PASS, FAIL o SKIPPED. Ang watchlist screening (checks.sanctions — CLEAR, MATCH o SKIPPED) ay add-on at lumalabas lang sa mga account na nag-enable nito.

Lifecycle ng session

Limang state, isang daan.

Kusang sumusulong ang session; hindi mo minamaneho ang state machine, binabasa mo lang ito.

Mga halaga ng status, ayon sa pagkakasunod.
PENDINGNagawa na. Wala pang nagbubukas ng verification_url.
IN_PROGRESSBinuksan ng aplikante ang link at nasa kung saang bahagi ng capture flow.
VERIFIEDTumakbo ang bawat check at handa na ang resulta. Terminal — tawagin ang result endpoint o basahin ang webhook.
FAILEDHindi bababa sa isang check ang hindi pumasa. Sinasabi ng failure_reason kung alin. Coming soon: isang retry na magre-reset ng session sa PENDING — hanggang noon, ituring na terminal ang FAILED at gumawa ng bagong session kung nais ng aplikanteng subukan muli.
EXPIREDWalang nakatapos sa takdang oras. Awtomatikong nag-e-expire ang mga session pagkaraan ng default na window (30 minuto); gumawa ng bago para subukan muli.

Kinakansela ng DELETE /v1/sessions/{id} nang maaga ang isang session na PENDING o IN_PROGRESS. Ang session na umabot na sa VERIFIED, FAILED o EXPIRED ay hindi na maaaring kanselahin — tapos na ito.

Mga error

Ang dapat paghandaan.

Ito ang shortlist na sulit i-code ngayon. Ang buo at kasalukuyang hanay ng mga error code at payload ay nakadokumento sa live OpenAPI sa /docs.

HTTP status, error code at ang kahulugan nito.
StatusCodeMeaning
401UNAUTHORIZEDNawawala ang X-Api-Key header.
401INVALID_KEY_FORMATHindi nagsisimula ang key sa vk_sand_ o vk_live_, o hindi tumutugma sa isang key sa account.
403FORBIDDENValid ang key ngunit walang access sa session o resource na hiniling mo.
404NOT_FOUNDWalang session, credential o resource na may ganoong id.
409CONFLICTWala ang session sa estadong nagpapahintulot sa aksyon — halimbawa, ang pagkansela ng session na VERIFIED na.
422VALIDATION_ERRORMay kinakailangang field na nawawala o mali ang anyo — halimbawa, ang return_url ay hindi valid na http o https URL.

Mga webhook

Pirmado, naihatid, muling sinubukan.

Kapag umabot sa VERIFIED o FAILED ang isang session, ipo-POST ng ShieldID ang hugis na nakadokumento sa itaas sa iyong webhook_url.

  • Inihahatid bilang POST na may JSON body na tumutugma sa hugis ng resulta sa itaas.
  • Pinirmahan gamit ang HMAC-SHA256 sa raw request body, ipinadala sa X-Bio-Signature header. I-verify ito laban sa iyong webhook secret bago mo pagkatiwalaan ang payload.
  • Muling sinusubukan hanggang tatlong beses na may linear backoff kung hindi sumasagot ang iyong endpoint ng 2xx status.
  • Coming soon: isang retry ng FAILED na session na maghahatid ng pangalawang webhook kapag nalutas na ito. Sa ngayon, ituring na panuntunan ang isang webhook bawat session.
  • Tumutugma sa reference na ito ang mga pangalan ng field dito. Kung iba ang aktwal na dumarating, pagkatiwalaan ang live payload kaysa sa pahinang ito at sabihin sa amin — sinasabayan ng listahan ng field ang API, hindi ang kabaligtaran.

I-verify ang signature

javascript
import crypto from "node:crypto";

function isValidShieldIdSignature(rawBody, signatureHeader, secret) {
  const expected = crypto.createHmac("sha256", secret).update(rawBody).digest("hex");
  const provided = signatureHeader || "";
  const a = Buffer.from(expected, "hex");
  const b = Buffer.from(provided, "hex");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

// rawBody must be the exact, unparsed request body
app.post("/hooks/shieldid", express.raw({ type: "application/json" }), (req, res) => {
  const ok = isValidShieldIdSignature(req.body, req.headers["x-bio-signature"], process.env.SHIELDID_WEBHOOK_SECRET);
  if (!ok) return res.status(401).send("invalid signature");

  const result = JSON.parse(req.body);
  // result.session_id, result.status, result.checks, …
  res.status(200).send("ok");
});

Idempotency at mga retry

Gumawa ng mga handler na ligtas patakbuhin nang dalawang beses.

Wala pang dedikadong idempotency key, sa paggawa ng session o sa paghahatid ng webhook.

  • Ang muling sinubukang paghahatid ng webhook ay maaaring dumating nang higit sa isang beses para sa iisang session. I-key ang iyong handler sa session_id + status at gawing idempotent ang pagsulat ng resulta.
  • Huwag basta-bastang i-retry ang POST /v1/sessions kapag nag-timeout — tingnan muna kung nagawa ang session, kung hindi ay maaaring magkaroon ng dalawang session para sa isang aplikante.
  • Nakaplano ang dedikadong Idempotency-Key header para sa paggawa ng session.

Malapit naSuporta sa Idempotency-Key sa paggawa ng session

Manatiling updated

Nagbabago ang reference na ito. Subaybayan ang changelog.

Doon muna inaanunsyo ang mga pagdaragdag ng field, bagong error code at pagbabago sa endpoint bago dumating dito.

Mga Tanong

FAQ ng Reference.

Susunod

Gamitin ang reference na ito.

Sundan ang quickstart para mapunta mula sa sandbox key hanggang sa verified session at signed webhook, ayon sa pagkakasunod-sunod.