メインコンテンツへスキップ
ShieldID

APIリファレンス

本人確認APIのリファレンスです。

呼び出せるすべてのエンドポイント、返されるすべてのフィールド、そしてwebhookが届いたときの対処方法を説明します。正確なフィールドの型については、お客様ご自身のAPIオリジンの/docsにある最新のOpenAPIドキュメントを正としてください。このページはそれをわかりやすく説明したものです。

ベースURLと環境

ベースURLは1つ、環境は2つ。

すべてのリクエストは同じホストに送られます。どの環境になるかは、送信するAPIキーによってのみ決まります。

このリファレンスのすべてのリクエストは、次の2つを前提としています。
ベースURL(本ドキュメント)https://api.shieldid.ca — illustrative; your production API origin is published together with your API keys.
認証ヘッダーX-Api-Key: <your key>。以下に記載する2つの公開エンドポイントを除き、すべてのリクエストで必要です。
Sandbox キーのプレフィックスvk_sand_… — このキーで作成されたセッションには environment: "sandbox" が付与され、課金されることはありません。
本番キーのプレフィックスvk_live_… — 同じリクエストでも、ご契約のプランに従って課金されます。
コンテンツタイプすべてのリクエストボディとレスポンスで application/json を使用します。

エンドポイント

v1 の全体像です。

JSON エンドポイントが6つあり、そのほかに、JSON ではないホスト型ページと公開の資格情報チェックがあります。これらはリンクするだけでご利用いただけます。

/v1配下のJSONエンドポイント。
EndpointAuthWhat it does
POST /v1/sessionsX-Api-Key検証セッションを作成します。return_url と webhook_url が必須です。session_id、verification_url、status: "PENDING" を返します。
GET /v1/sessions/{id}X-Api-Key1つのセッションのステータスと主要フィールド(status、confidence、environment)です。
GET /v1/sessions/{id}/resultX-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-Key2文字の ISO 3166-1 国コードごとの料金です。
リンク先として案内するページであり、解析するJSONではありません。
/v/{session_id}ホスト型の検証ページです。セッションが返す verification_url にあたります。デスクトップでは QR コードが表示され、スキャンすると申請者のスマートフォンに同じリンクが渡され、書類とセルフィーを撮影できます。
/c/{session_id}検証済みの1つのセッションに対する、認証不要の公開資格情報チェックページです。注意:現在のレスポンスには、有効/無効のフラグだけでなく、検証された本人の氏名と書類の種類・国も含まれます。これらを見せたくない第三者にこのリンクを渡さないでください。
/docsお客様のアカウントの API オリジン向けの、ライブでインタラクティブな OpenAPI リファレンスです。

セッションの作成

POST /v1/sessions を最初から最後まで解説します。

リクエストと、返されるレスポンスの内容を正確に示します。

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 — リクエストフィールド。
return_urlstring、必須 — 申請者が手続きを終えた後に戻される先です。http または https である必要があります。
webhook_urlstring、必須 — 署名付きの結果が配信される先です。下記の Webhook をご覧ください。
expected_namestring、必須 — 書類に記載されているはずの氏名です。ID に実際に記載されている内容との照合に使用されます。
expected_dob / expected_addressstring、任意 — 指定された場合は書類と照合されます。検証の実行に必須ではありません。
localestring、任意 — "en" または "fr"。申請者に表示されるホスト型ページの言語を設定します。
metadataobject、任意 — お客様独自の参照データです。申請 ID やテナント ID など、結果と Webhook にそのまま返したいものを自由に指定できます。

結果

GET /v1/sessions/{id}/result — レスポンスの形式。

同じ形式が Webhook ペイロードでも配信されるため、このエンドポイントをポーリングする必要はほとんどありません。

トップレベルのフィールド。
session_id作成した ID です。
statusPENDING、IN_PROGRESS、VERIFIED、FAILED または EXPIRED。
environment"sandbox" または "production"。セッションを作成したキーに対応します。
person書類から読み取られた項目:氏名、生年月日、書類の種類、書類の発行国と管轄、住所。
checksチェックごとに1つの判定が返されます(下記参照)。不透明な単一のスコアは返しません。
confidence本人確認全体に対する単一の総合値です。顔照合を含む個々のチェックは、引き続き固定の判定基準に照らして個別に報告されます。このフィールドがそれらに代わるものではありません。
verified_untilVERIFIEDのセッションで、結果が有効とみなされる期間です。
failure_reasonFAILEDのセッションで設定されます(例:FACE_MATCH_BELOW_THRESHOLD、CANCELLED_BY_API)。それ以外の場合はnullです。
metadataセッション作成時に送信した内容が、そのまま返されます。
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-onchecks.document、checks.liveness、checks.antispoof、checks.face_matchは、それぞれPASS、FAIL、SKIPPEDのいずれかになります。ウォッチリストスクリーニング(checks.sanctions — CLEAR、MATCH、SKIPPED)はアドオンで、有効にしているアカウントにのみ表示されます。

セッションのライフサイクル

5つの状態、1つの経路。

セッションは自動的に先へ進みます。ステートマシンを操作する必要はなく、状態を読み取るだけです。

statusの値(順序どおり)。
PENDING作成済み。まだ誰もverification_urlを開いていません。
IN_PROGRESS申請者がリンクを開き、撮影フローの途中にいます。
VERIFIEDすべてのチェックが実行され、結果が準備できています。最終状態です。結果エンドポイントを呼び出すか、webhookを読み取ってください。
FAILED少なくとも1つのチェックに合格しませんでした。理由はfailure_reasonに示されます。近日公開:セッションをPENDINGにリセットする再試行機能。それまでは、FAILEDを最終状態として扱い、申請者が再試行を希望する場合は新しいセッションを作成してください。
EXPIRED時間内に誰も完了しませんでした。セッションは、デフォルトの期間(30分)が過ぎると自動的に期限切れになります。再試行するには、新しいセッションを作成してください。

DELETE /v1/sessions/{id} は、PENDING または IN_PROGRESS のセッションを途中でキャンセルします。すでに VERIFIED、FAILED、または EXPIRED になったセッションは、すでに完了しているためキャンセルできません。

エラー

想定しておくべきこと。

ここには、現時点で実装の対象にすべき主なものを掲載しています。エラーコードとペイロードの最新かつ完全な一覧は、/docsにある最新のOpenAPIに記載されています。

HTTPステータス、エラーコード、およびその意味。
StatusCodeMeaning
401UNAUTHORIZEDX-Api-Keyヘッダーがありません。
401INVALID_KEY_FORMATキーがvk_sand_またはvk_live_で始まっていないか、アカウント上のキーと一致していません。
403FORBIDDENキーは有効ですが、リクエストしたセッションまたはリソースへのアクセス権がありません。
404NOT_FOUNDそのIDのセッション、認証情報、またはリソースは存在しません。
409CONFLICTセッションがそのアクションを許可する状態ではありません。たとえば、すでに VERIFIED になっているセッションをキャンセルしようとした場合などです。
422VALIDATION_ERROR必須フィールドがないか、形式が正しくありません。例:return_urlが有効なhttpまたはhttpsのURLではない場合。

Webhook

署名され、配信され、再試行されます。

セッションがVERIFIEDまたはFAILEDに達すると、ShieldIDは上記の形式のデータをお客様のwebhook_urlにPOSTします。

  • 上記の結果の形式に一致するJSON本文を持つPOSTとして配信されます。
  • リクエストの生の本文に対するHMAC-SHA256で署名され、X-Bio-Signatureヘッダーで送信されます。ペイロードを信頼する前に、webhookシークレットで検証してください。
  • エンドポイントが2xxステータスで応答しない場合、線形バックオフで最大3回まで再試行されます。
  • 近日公開:FAILEDセッションの再試行機能。解決後に2つ目のwebhookを配信します。現時点では、セッションごとに1つのwebhookを前提としてください。
  • ここに記載のフィールド名は、このリファレンスと一致しています。実際に届く内容が異なる場合は、このページよりも実際のペイロードを信頼し、ぜひお知らせください。フィールド一覧はAPIに合わせて更新されるものであり、その逆ではありません。

署名を検証する

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");
});

べき等性と再試行

2回実行しても安全なハンドラーを構築してください。

セッション作成時にも、webhook配信時にも、専用のべき等性キーはまだありません。

  • 再試行されたwebhookの配信が、同じセッションに対して複数回届くことがあります。ハンドラーはsession_id + statusをキーとし、結果の書き込みをべき等にしてください。
  • タイムアウトしたからといって、POST /v1/sessionsをむやみに再試行しないでください。まずセッションが作成されたかどうかを確認しないと、1人の申請者に対して2つのセッションができてしまう可能性があります。
  • セッション作成用の専用Idempotency-Keyヘッダーを予定しています。

近日公開セッション作成時のIdempotency-Keyのサポート

最新情報の確認

このリファレンスは変更されます。変更履歴をご確認ください。

フィールドの追加、新しいエラーコード、エンドポイントの変更は、こちらに反映される前に変更履歴で告知されます。

ご質問

リファレンスのFAQ。

次へ

このリファレンスを活用しましょう。

クイックスタートに沿って、sandbox キーから検証済みセッション、署名付き Webhook まで順番に進めてみましょう。