مرجع API
مرجع API احراز هویت.
هر نقطهٔ پایانی که میتوانید فراخوانی کنید، هر فیلدی که در پاسخ میبینید، و کاری که باید پس از رسیدن یک webhook انجام دهید. برای انواع دقیق فیلدها، سند OpenAPI زنده در /docs روی origin API خودتان را مرجع اصلی بدانید — این صفحه روایت سادهشدهٔ آن است.
نشانی پایه و محیطها
یک نشانی پایه. دو محیط.
همهٔ درخواستها به یک میزبان واحد میروند. اینکه در کدام محیط هستید، فقط با این تعیین میشود که کدام کلید API را ارسال میکنید.
| نشانی پایه (این مستندات) | https://api.shieldid.ca — illustrative; your production API origin is published together with your API keys. |
|---|---|
| هدر احراز هویت | X-Api-Key: <your key>، در هر درخواست بهجز دو نقطه پایانی عمومی که در ادامه آمدهاند. |
| پیشوند کلید Sandbox | vk_sand_… — نشستهای ایجادشده با این کلید با environment: "sandbox" علامتگذاری میشوند و هرگز صورتحساب نمیشوند. |
| پیشوند کلید محیط عملیاتی | vk_live_… — همان درخواستها، با هزینهای بر اساس طرح شما. |
| نوع محتوا | application/json برای بدنه و پاسخ هر درخواست. |
نقاط پایانی
سطح کامل v1.
شش نقطه پایانی JSON، بهعلاوه یک صفحه میزبانیشده و یک بررسی عمومی اعتبارنامه که اصلاً JSON نیستند — فقط پیوند آنها را میدهید.
| Endpoint | Auth | What it does |
|---|---|---|
| POST /v1/sessions | X-Api-Key | ایجاد یک نشست تأیید هویت. به return_url و webhook_url نیاز دارد. session_id، verification_url و status: "PENDING" را برمیگرداند. |
| GET /v1/sessions/{id} | X-Api-Key | وضعیت و فیلدهای اصلی یک نشست: status، confidence، environment. |
| GET /v1/sessions/{id}/result | X-Api-Key | نتیجه کامل پس از آنکه نشست به VERIFIED یا FAILED برسد: person، نتایج هر بررسی، confidence، verified_until. |
| DELETE /v1/sessions/{id} | X-Api-Key | نشستی را که هنوز PENDING یا IN_PROGRESS است لغو کنید. نشستی که پیشتر به VERIFIED، FAILED یا EXPIRED رسیده باشد قابل لغو نیست. |
| GET /v1/credentials/{token} | None — public | بررسی میکند که آیا یک اعتبارنامه تأییدشده در حال حاضر معتبر است یا نه. نیازی به کلید API ندارد، بنابراین از مرورگر قابل فراخوانی است. توجه: پاسخ فعلی علاوه بر نشانگر معتبر/نامعتبر، نام فرد تأییدشده و نوع/کشور سند را نیز شامل میشود — این پیوند را به شخص ثالثی که نمیخواهید این اطلاعات را ببیند ندهید. |
| GET /v1/pricing/{country} | X-Api-Key | قیمتگذاری هر کشور برای یک کد کشور دوحرفی ISO 3166-1. |
| /v/{session_id} | صفحه تأیید میزبانیشده — همان verification_url که یک نشست برمیگرداند. در دسکتاپ یک کد QR نمایش میدهد؛ اسکن آن همان پیوند را به تلفن متقاضی میدهد تا سند و سلفی خود را ثبت کند. |
|---|---|
| /c/{session_id} | یک صفحه عمومی و بدون احراز هویت برای بررسی اعتبارنامه یک نشست تأییدشده. توجه: پاسخ فعلی علاوه بر نشانگر معتبر/نامعتبر، نام فرد تأییدشده و نوع/کشور سند را نیز شامل میشود — این پیوند را به شخص ثالثی که نمیخواهید این اطلاعات را ببیند ندهید. |
| /docs | مرجع OpenAPI زنده و تعاملی برای مبدأ API حساب شما. |
ایجاد یک جلسه
POST /v1/sessions، از ابتدا تا انتها.
درخواست و دقیقاً آنچه بازگردانده میشود.
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" }
}'| return_url | string، الزامی — نشانیای که متقاضی پس از پایان کار به آن بازگردانده میشود. باید http یا https باشد. |
|---|---|
| webhook_url | string، الزامی — نشانیای که نتیجه امضاشده به آن ارسال میشود. در بخش وبهوکها در ادامه ببینید. |
| expected_name | string، الزامی — نامی که انتظار دارید روی سند باشد؛ برای مطابقتدادن با آنچه واقعاً روی کارت شناسایی نوشته شده استفاده میشود. |
| expected_dob / expected_address | string، اختیاری — در صورت ارائه، با سند مطابقت داده میشود؛ برای اجرای تأیید هویت الزامی نیست. |
| locale | string، اختیاری — "en" یا "fr". زبان صفحه میزبانیشدهای را که متقاضی میبیند تعیین میکند. |
| metadata | object، اختیاری — دادههای مرجع خودتان — شناسه درخواست، شناسه tenant یا هر چیزی که میخواهید بدون تغییر در نتیجه و وبهوک بازگردانده شود. |
نتیجه
GET /v1/sessions/{id}/result — ساختار پاسخ.
همین ساختار در محتوای وبهوک نیز ارسال میشود، بنابراین بهندرت نیاز دارید این نقطه پایانی را پیمایش (poll) کنید.
| session_id | شناسهای که ایجاد کردید. |
|---|---|
| status | PENDING، IN_PROGRESS، VERIFIED، FAILED یا EXPIRED. |
| environment | "sandbox" یا "production"، متناسب با کلیدی که نشست را ایجاد کرده است. |
| person | فیلدهای خواندهشده از مدرک: نام، تاریخ تولد، نوع مدرک، کشور و حوزهٔ صدور مدرک، نشانی. |
| checks | یک حکم برای هر بررسی — در ادامه ببینید. هرگز یک امتیاز مبهم و واحد نیست. |
| confidence | یک عدد کلی برای احراز هویت. بررسیهای جداگانه، از جمله تطابق چهره، همچنان بهطور مستقل و در برابر یک خط تصمیم ثابت گزارش میشوند — این فیلد جایگزین آنها نمیشود. |
| verified_until | مدت زمانی که نتیجه معتبر تلقی میشود، برای نشستی با وضعیت VERIFIED. |
| failure_reason | برای نشستی با وضعیت FAILED مقداردهی میشود — برای مثال FACE_MATCH_BELOW_THRESHOLD یا CANCELLED_BY_API. در غیر این صورت null است. |
| metadata | هر آنچه هنگام ایجاد نشست فرستادهاید، بدون هیچ تغییری. |
{
"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-onchecks.document، checks.liveness، checks.antispoof و checks.face_match هرکدام به PASS، FAIL یا SKIPPED ختم میشوند. غربالگری فهرستهای تحریم و نظارت (checks.sanctions — با مقادیر CLEAR، MATCH یا SKIPPED) یک افزونه است و فقط برای حسابهایی که آن را فعال کردهاند نمایش داده میشود.
چرخهٔ حیات نشست
پنج وضعیت، یک مسیر.
نشست خودش به جلو حرکت میکند؛ شما ماشین حالت را هدایت نمیکنید، فقط آن را میخوانید.
| PENDING | ایجاد شده. هنوز کسی verification_url را باز نکرده است. |
|---|---|
| IN_PROGRESS | متقاضی پیوند را باز کرده و در جایی از مراحل ثبت مدرک است. |
| VERIFIED | همهٔ بررسیها اجرا شده و نتیجه آماده است. وضعیت نهایی — نقطهٔ پایانی نتیجه را فراخوانی کنید یا webhook را بخوانید. |
| FAILED | دستکم یکی از بررسیها موفق نبوده است. failure_reason مشخص میکند کدام. بهزودی: امکان تلاش مجدد که نشست را به PENDING بازمیگرداند — تا آن زمان، FAILED را وضعیت نهایی بدانید و اگر متقاضی میخواهد دوباره تلاش کند، نشست جدیدی ایجاد کنید. |
| EXPIRED | کسی در زمان مقرر کار را کامل نکرده است. نشستها پس از یک بازهٔ پیشفرض (30 دقیقه) بهطور خودکار منقضی میشوند؛ برای تلاش دوباره نشست جدیدی ایجاد کنید. |
DELETE /v1/sessions/{id} یک نشست PENDING یا IN_PROGRESS را زودتر لغو میکند. نشستی که پیشتر به VERIFIED، FAILED یا EXPIRED رسیده باشد قابل لغو نیست — کار آن پیشتر تمام شده است.
خطاها
برای چه مواردی باید برنامهریزی کرد.
این فهرست کوتاهِ مواردی است که امروز ارزش دارد کدنویسی شما بر پایهٔ آنها باشد. مجموعهٔ کامل و بهروز کدهای خطا و payloadها در OpenAPI زنده در /docs مستند شده است.
| Status | Code | Meaning |
|---|---|---|
| 401 | UNAUTHORIZED | هدر X-Api-Key وجود ندارد. |
| 401 | INVALID_KEY_FORMAT | کلید با vk_sand_ یا vk_live_ شروع نمیشود، یا با هیچ کلیدی در حساب مطابقت ندارد. |
| 403 | FORBIDDEN | کلید معتبر است اما به نشست یا منبعی که درخواست کردهاید دسترسی ندارد. |
| 404 | NOT_FOUND | هیچ نشست، اعتبارنامه یا منبعی با این شناسه وجود ندارد. |
| 409 | CONFLICT | نشست در وضعیتی نیست که اجازهی این اقدام را بدهد — برای مثال، لغو نشستی که پیشتر VERIFIED شده است. |
| 422 | VALIDATION_ERROR | یک فیلد الزامی وجود ندارد یا قالب آن نادرست است — برای مثال، return_url یک نشانی http یا https معتبر نیست. |
وبهوکها
امضاشده، تحویلشده، با تلاش مجدد.
وقتی نشستی به VERIFIED یا FAILED برسد، ShieldID ساختار مستندشده در بالا را با POST به webhook_url شما ارسال میکند.
- بهصورت POST و با بدنهٔ JSON مطابق ساختار نتیجهٔ بالا تحویل داده میشود.
- با HMAC-SHA256 روی بدنهٔ خام درخواست امضا شده و در هدر X-Bio-Signature ارسال میشود. پیش از اعتماد به payload، آن را با راز webhook خود راستیآزمایی کنید.
- اگر نقطهٔ پایانی شما با وضعیت 2xx پاسخ ندهد، تا سه بار با backoff خطی دوباره تلاش میشود.
- بهزودی: تلاش مجدد برای نشست FAILED که پس از نهایی شدن، webhook دومی تحویل میدهد. امروز، یک webhook برای هر نشست را قاعده بدانید.
- نام فیلدها در اینجا با این مرجع مطابقت دارد. اگر آنچه عملاً دریافت میکنید متفاوت به نظر میرسد، به payload زنده اعتماد کنید و به ما اطلاع دهید — فهرست فیلدها با API هماهنگ نگه داشته میشود، نه برعکس.
بررسی امضا
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 و تلاش مجدد
کنترلکنندههایی بسازید که اجرای دوبارهشان بیخطر باشد.
هنوز کلید idempotency اختصاصی وجود ندارد، نه برای ایجاد نشست و نه برای تحویل webhook.
- تحویل مجدد یک webhook ممکن است برای یک نشست بیش از یک بار برسد. کنترلکنندهٔ خود را بر اساس session_id + status کلیدگذاری کنید و ثبت نتیجه را idempotent کنید.
- POST /v1/sessions را هنگام timeout کورکورانه دوباره تلاش نکنید — ابتدا بررسی کنید نشست ایجاد شده است یا نه، وگرنه ممکن است برای یک متقاضی دو نشست داشته باشید.
- یک هدر اختصاصی Idempotency-Key برای ایجاد نشست در برنامه است.
بهزودیپشتیبانی از Idempotency-Key در ایجاد نشست
همگام ماندن
این مرجع تغییر میکند. تغییرنامه را دنبال کنید.
افزوده شدن فیلدها، کدهای خطای جدید و تغییرات نقاط پایانی پیش از آنکه در اینجا بیایند، در آنجا اعلام میشوند.
پرسشها
پرسشهای متداول مرجع.
بعدی
از این مرجع در عمل استفاده کنید.
راهنمای شروع سریع را دنبال کنید تا به ترتیب از یک کلید sandbox به یک نشست تأییدشده و یک وبهوک امضاشده برسید.