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

認証

すべての管理APIエンドポイントでは、アプリケーションのAPIキーを使用します。URLに組織やアプリのUUIDを含める必要はありません。アプリケーションはキーから識別されます。
まだAPIキーをお持ちでない場合は、2回のAPI呼び出しでプログラムで登録できます。

ワークフロー

ワークフローは、ユーザーが行う検証ステップ(身分証のスキャン、ライブネス検知、顔照合、AMLスクリーニングなど)を定義します。各ワークフローは、セッションに紐付けて再利用できる設定です。
GET
アプリケーションのすべてのワークフローを一覧表示します。各ワークフローの機能、しきい値、デフォルトかどうかを返します。
POST
新しいワークフローを作成します。有効にする検証機能の指定、しきい値の設定、受け付ける書類の種類の設定などを行えます。
GET
特定のワークフローについて、すべての機能設定としきい値を含む詳細を取得します。
PATCH
ワークフローの設定を更新します。任意の機能設定、しきい値、受け付ける書類を変更できます。
DELETE
ワークフローを削除します。すでにこのワークフローを使用しているセッションには影響しません。
ワークフローの作成と設定には、Business Consoleの使用を強く推奨します。ビジュアルワークフロービルダーでは、テンプレート、ドラッグ&ドロップによる機能設定、書類の設定、しきい値の調整、プレビューを、コードを書かずにすべて利用できます。APIは、ワークフローの自動化やプログラムによる管理にのみ使用してください。

簡単な例: ワークフローの作成

workflow_typeによって基本となる機能セットが決まります。その上で、個々の機能をis_*_enabledフラグで切り替えます。
指定できるworkflow_typeの値: kyc、kyb、adaptive_age_verification、biometric_authentication、address_verification、questionnaire_verification、email_verification、phone_verification。 kycワークフローでは本人確認が自動的に含まれるため、そのための個別のフラグは不要です。is_*_enabledフラグを使用して、顔照合、ライブネス検知、AML、NFC、電話番号認証、メールアドレス認証、住所証明、デバイス・IP分析などのオプション機能を追加または削除します。 次に、セッションを作成する際にそのワークフローを使用します。

アンケート

ユーザーから追加情報を収集するために、検証ワークフローに追加できるカスタムフォームです。
GET
すべてのアンケートを一覧表示します。
POST
カスタムの質問、分岐ロジック、翻訳を含む新しいアンケートを作成します。
GET
すべての質問とフォーム構造を含むアンケートの詳細を取得します。
PATCH
アンケートを更新します。
DELETE
アンケートを削除します。

ユーザー

アプリケーション内の検証済みの個人(ユーザー)を管理します。各ユーザーは、セッション作成時に指定するvendor_data文字列で識別されます。
GET
アプリケーションのすべてのユーザーを、検証ステータスとセッション履歴を含めて一覧表示します。
GET
vendor_data識別子でユーザーの詳細を取得します。
PATCH
ユーザーのメタデータを更新します。
POST
ユーザーを一括削除します。ボディ: {"vendor_data_list": ["user-1", "user-2"]}または{"delete_all": true}。対象ユーザーについて保持されているすべての生体認証テンプレートも完全に削除されます。

生体認証テンプレート

オプトインしたアプリケーションがセッション削除後も保持する、画像を含まない顔の生体認証テンプレートです。生体認証テンプレートを参照してください。
GET
フィルター(vendor_data、vendor_user_uuid、status、source_type、retained_from、retained_to、ordering)付きのページ分割された一覧です。
GET
同じフィルターを使用した件数です。
GET
1件のテンプレート: 所有するユーザー、取得元の参照、有効期限、指示、ステータス。
DELETE
1件のテンプレートを完全に削除します。{"uuid": "...", "outcome": "purged" | "already_purged"}を返します。
POST
一括で完全に削除します。ボディ: {"template_uuids": [...]}または{"delete_all": true}に、任意でフィルターを追加します。

セッション操作

POST
セッションを一括削除します。delete:sessionsが必要です。ボディ: {"session_numbers": ["1", "2", "3"]}または{"delete_all": true}(delete_allの対象は、filter_statusのようにfilter_を接頭辞に付けたList Sessionsのフィルターで絞り込めます)に、任意でretain_face_embeddings、face_retention_days、face_retention_deadline、deletion_instruction、instruction_idを追加します。該当するセッションが20件以下の場合はセッション1件あたりのface_retention_outcomeとともに200を返し、それを超える場合は削除ジョブとともに202を返します。
GET
202を返したセッション一括削除の進捗と結果別の件数です。
GET
セッションのレビューとアクティビティログを一覧表示します。
POST
セッションにレビューメモまたはステータス変更を追加します。

請求

GET
現在のクレジット残高と自動チャージ設定を取得します。
POST
クレジットをチャージするためのStripeチェックアウトセッションを作成します。1回のチャージ額は$50から$10,000で、額面どおりに加算されます。

リスト (ブロックリスト・許可リスト・カスタムリスト)

ブロックリスト、許可リスト、ワークフローのカスタム条件に使う型付きリストを管理します。詳しくはLists APIドキュメントを参照してください。
GET
アプリケーションのすべてのリスト(ブロックリスト、許可リスト、カスタムリスト)を一覧表示します。
POST
リストにエントリーを追加します。reference_session_idを指定するとセッションからデータを自動抽出でき、reference_object_uuidを指定すると取引・ユーザー・企業へのトレーサビリティを確保できます。
DELETE
リストからエントリーを削除します。
POST
顔のブロックリストに顔画像(base64)をアップロードします。

Webhook設定

GET
URL、バージョン、Webhook署名の検証に使うシークレットキー、アプリケーションのデータ保持ポリシーと生体認証テンプレートの保持ポリシーを含む、現在のWebhook設定を取得します。 レスポンスにはallowed_domainsも含まれます。詳細は後述のPATCH /v3/webhook/を参照してください。
PATCH
Webhook URLやバージョンを更新するか、シークレットキーをローテーションします。rotate_secret_key: trueを指定すると新しいWebhookシークレットが生成されます(古いシークレットは直ちに無効になります)。アプリケーションの保持ポリシーもここで設定します。設定項目はdata_retention_monthsとface_retention_policy(デフォルトはdelete_with_session、またはretain_until_user_deleted)で、保持を有効にする場合はface_retention_days(1〜3650)の指定が必須です。生体認証テンプレートの保持を参照してください。また、allowed_return_hostsも登録します。これは、Digital ID wallet APIによる認証でHTTPSを介して本人を戻せるホスト名を最大20個(例: app.example.com。スキーム、ポート、パス、ワイルドカードは含めません)です。新しいリストを送ると登録済みのリストが置き換えられます。アプリケーションのホワイトラベルドメインは常に許可されます。allowed_domainsもここで設定します。これは、ホスト型検証フローを埋め込めるウェブオリジン、およびセッションのcallbackでユーザーを戻せるウェブオリジンを最大50個まで指定するものです(例: https://app.example.com)。 各エントリーはスキーム、ホスト、任意のポートで構成し、パス、クエリ、ワイルドカードは含めません。 httpsを使用してください。httpはlocalhost、127.0.0.1、::1の場合にのみ受け付けます。 Didit は各オリジンを小文字に変換し、デフォルトポートを除いて保存したうえで、そのリストをallowed_domainsで返します。 無効なエントリーがある場合、allowed_domainsに対して400エラーが返されます。 新しいリストを送ると登録済みのリストが置き換えられ、空のリストを送ると制限が解除されます。 リストが空でない間は、POST /v3/session/はリストに含まれないウェブcallbackを400エラーで拒否します。また、ホスト型フローは、リストに含まれない保存済みのコールバックやワークフローのデフォルトコールバックにユーザーをリダイレクトしません。 カスタムURLスキーム(アプリのディープリンク)とサーバー間のAPI呼び出しは影響を受けません。endpointsを送信すると、そのリストに含まれないWebhookの送信先はすべて、署名シークレットおよび配信ログ全体とともに完全に削除されます。これはDELETE /v3/webhook/destinations/{destination_uuid}/とまったく同じ動作です。 この操作は元に戻せません。 送信先を1件ずつ管理する場合は、代わりにWebhookの送信先エンドポイントを使用してください。

APIエンドポイント一覧

最終更新日 2026年11月1日