メインコンテンツへスキップ
このガイドでは、REST API経由でDiditの本人確認を組み込むための一連の流れを説明します。認証情報の取得、セッションの作成、ユーザーへの提示、結果の受信までを扱います。

ステップ1:認証情報を取得する

api_keyを取得する方法は2つあります。

オプションA:プログラムによる登録(ブラウザ不要)

CI/CDやAIエージェントに最適です。POST /programmatic/register/、続いてPOST /programmatic/verify-email/の2回のAPI呼び出しで、api_keyがレスポンス内で直接返されます。 → 全体の流れ、パスワードのルール、JWTの有効期間、ロックアウトポリシーについてはプログラムによる登録を参照してください。

オプションB:Didit Consoleから取得する

  1. Didit Consoleにアクセスします。
  2. 組織を作成または選択します。
  3. Settings → API & Webhooksに移動します。
  4. 次の値をコピーします。
    • API Key:すべての認証呼び出しでx-api-keyヘッダーとして使用します。
    • Webhook Secret Key:WebhookのHMAC署名の検証に使用します。

環境変数


ステップ2:ワークフローを作成する

セッションを作成する前に、認証用のワークフローが必要です。ワークフローは、ユーザーが進む認証ステップを定義します。

Consoleで作成する

  1. Didit Console → Workflowsに移動します
  2. Create Workflowをクリックします
  3. ベースとなるテンプレートを選択します。
  1. 任意の機能を追加します。
  1. Workflow IDをコピーします
詳細な設定オプションについては、ワークフローのドキュメントを 参照してください。

ステップ3: 検証セッションを作成する

APIを呼び出して、ユーザーのセッションを作成します。

リクエスト

リクエストパラメーター

すべてのオプションを含む完全な例

expected_details.expected_document_typesは、本人確認ステップを 特定の書類タイプに制限します。書類選択画面には指定したタイプのみが 表示されます。指定可能な値: P(パスポート)、ID(国民IDカード)、DL (運転免許証)、RP(在留許可証)、HIC(健康保険証)、 TC(税務カード)、SSC(社会保障カード)。値は大文字と小文字を区別せず、 重複は除去されます。不明な値を指定すると400が返されます。完全なスキーマは Create Sessionリファレンスを参照してください。

レスポンス

201 Created:

主なレスポンスフィールド

冪等性。 vendor_dataが指定され、同じvendor_dataを持つ 未完了のセッション(Not Started、In Progress、Resubmitted、Awaiting User)が ワークフローの最新の公開バージョンにすでに存在する場合、 重複を作成せずにその既存セッションが返されます(この場合も201)。 その際、callbackとmetadataは新しい値に更新され、 statusは既存セッションの状態を反映します。
x-api-keyがない場合は403が返されます。 本文は {"detail": "You do not have permission to perform this action."}で、 権限のない有効なキーの場合と同じです。誤った、失効した、または期限切れの キーでは401が返されます。クレジットが不足している場合は 400が返されます。詳細なドキュメントはCreate Session APIリファレンスを 参照してください。

ステップ4: ユーザーに検証を表示する

ユーザーに検証フローを表示する方法を選択してください。

オプションA: ネイティブSDK (モバイルに推奨)

カメラ、NFC、生体認証との連携には、session_tokenをネイティブSDKで使用します。 → iOS SDK · Android SDK · React Native · Flutter

オプションB: InContext iframe (Webに推奨)

ステップ3で返されたurlを使用して、ページ内に検証を埋め込みます。
→ InContext iframe

オプションC: リダイレクト

ユーザーを検証URLにリダイレクトします。
→ Webリダイレクト

オプションD: モバイルWebView

ネイティブSDKがないモバイルアプリ向けです。
→ iOS/AndroidのWebView

ステップ5: 結果を受け取る

Webhookで受け取る (推奨)

Webhookは、認証ステータスが変わるとリアルタイムでサーバーに通知します。 設定:
  1. Console (API & Webhooks) で、またはPOST /v3/webhook/destinations/を使用して、webhook_version: "v3"とsubscribed_events配列 (例: ["status.updated"]) を指定してWebhookの送信先を作成します
  2. 作成時に返されるsecret_shared_keyを保存します。これはすべての署名方式で使用するHMACシークレットです
  3. サーバーにWebhookエンドポイントを実装します
Webhookペイロードの例: decisionの中では、機能ごとのすべての結果が複数形の配列 (id_verifications[]、nfc_verifications[]、liveness_checks[]、face_matches[]、…) として配信され、ワークフロー内のノード1つにつき1エントリが含まれます。これはV3の契約であり、絶対に変わりません。単数形のnfc / id_verification / livenessキーを前提にコードを書かないでください。
decisionオブジェクトは、statusがApproved、Declined、In Review、Abandonedのいずれかの場合にのみ含まれます (Resubmittedイベントには代わりにresubmit_infoが含まれます)。Diditは再試行時や複数の送信先へのファンアウト時にも同じevent_idを使用するため、冪等性のキーにはこの値を使用してください。すべての複数形の配列とフィールドについてはデータモデルを参照してください。 署名を検証する (X-Signature-V2、推奨): X-Signature-V2は、JSONボディを正規化して再エンコードしたものに対するHMAC-SHA256です。正規化では、整数値の浮動小数点数を整数に短縮し、キーを再帰的にソートし、区切り文字を詰め、Unicodeをそのまま保持します。
→ Webhookの完全なドキュメントでは、生のバイト列に対するX-Signature、非推奨のエンベロープのみを対象とするX-Signature-Simple、およびその選び方を説明しています。Diditは失敗した配信 (5xx、404、タイムアウト) を最大2回 (約1分後、次に約4分後) 再試行し、5 秒でタイムアウトします。すばやく2xxを返してください。

APIで取得する (任意)

同じ判定ペイロードはいつでも取得できます:
レスポンスの構造 (複数形の配列) はWebhookペイロード内のdecisionオブジェクトと同一で、このエンドポイントはセッションのライフサイクルのどの時点でも呼び出せます。リアルタイムの更新にはWebhookを使用し、APIの呼び出しはバックフィル、監査、再構築用にとどめてください。/decision/エンドポイントには、APIキーごとに毎分600件のGETリクエストというレート制限があります (レート制限を参照)。エラーの扱い: 不明なsession_idの場合は404と{"detail": "Not found."}が返り、認証の失敗は403として返ります。このエンドポイントが401を返すことはありません。レスポンス内のメディアURLは有効期間の短い署名付きリンクです。保存せずに、すみやかに取得してください。 → セッション取得APIリファレンス

完全なコード例

Node.js / Express

Python / FastAPI


セッションのステータス

statusが取りうる値は次の10種類で、大文字と小文字を区別する厳密な文字列です (Kyc Expiredは先頭のKのみが大文字である点に注意してください): ライフサイクル全体、状態遷移、Mermaid図については認証ステータスを参照してください。

次のステップ

  1. 連携方法を選ぶ:
  2. Webhookを設定: Webhook
  3. 必要な処理能力を見積もる: レート制限
  4. すべてのステータスに対応する: 認証ステータス
  5. ワークフローをカスタマイズする: ワークフロー
  6. APIに接続できることを確認する: ヘルスチェック

お困りの場合

最終更新日 2026年11月1日