認証
すべての管理APIエンドポイントでは、アプリケーションのAPIキーを使用します。URLに組織やアプリのUUIDを含める必要はありません。アプリケーションはキーから識別されます。ワークフロー
ワークフローは、ユーザーが行う検証ステップ(身分証のスキャン、ライブネス検知、顔照合、AMLスクリーニングなど)を定義します。各ワークフローは、セッションに紐付けて再利用できる設定です。GET
アプリケーションのすべてのワークフローを一覧表示します。各ワークフローの機能、しきい値、デフォルトかどうかを返します。
POST
新しいワークフローを作成します。有効にする検証機能の指定、しきい値の設定、受け付ける書類の種類の設定などを行えます。
GET
特定のワークフローについて、すべての機能設定としきい値を含む詳細を取得します。
PATCH
ワークフローの設定を更新します。任意の機能設定、しきい値、受け付ける書類を変更できます。
DELETE
ワークフローを削除します。すでにこのワークフローを使用しているセッションには影響しません。
簡単な例: ワークフローの作成
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の送信先エンドポイントを使用してください。