メインコンテンツへスキップ
POST
cURL
このエンドポイントを使うと、ワークフローのグラフノードを自分で構築しなくても、APIでワークフローを作成できます。ユーザーにチェックを完了してもらう順序でfeatures配列を送信してください。Diditはこれを内部でノードベースのワークフローに変換し、最終ステータスのステップを自動的に追加します。 このPOST /v3/workflows/エンドポイントで作成できるのは、フラットなfeaturesリストによるシンプルで直線的なワークフローのみです。分岐、条件付きルーティング、Document AI、却下・判定ノードを使う場合は、以下で説明するノードのグラフ形式を使用してください(コンソールのビジュアルビルダーとDidit MCPのワークフローツールもこの形式で動作しています)。 各機能が受け付けるすべてのconfigフィールドについては、ワークフロー機能の設定を参照してください。

基本的なKYCワークフロー

アンケートワークフロー

まずPOST /v3/questionnaires/でアンケートを作成します。次に、返されたquestionnaire_idをquestionnaire_uuidとして使用します。
機能の順序は重要です。たとえば、書類データに依存するFACE_MATCH、NFC、DATABASE_VALIDATION、またはユーザーのAMLチェックより前にOCRを配置してください。

機能設定リファレンス

features[]の各項目は次の形式です。
configオブジェクトの正確な内容は機能によって異なります。フィールドの完全な一覧、デフォルト値、必須設定、値の範囲、例についてはワークフロー機能の設定を確認してください。 OCRでは、config.documents_allowedを省略するか、nullまたは{}を送信すると、サポートされているすべての書類タイプが許可されます。特定の国や書類タイプにワークフローを限定したい場合にのみ含めてください。QUESTIONNAIREでは、config.questionnaire_uuidが必須です。

オプションのワークフロー設定

ワークフローの作成時に以下のトップレベルフィールドを含めることで、セッションの動作を制御できます。いずれも任意で、省略した場合はワークフローのデフォルト値が使用されます。

分岐とノードベースのワークフロー (グラフ)

直線的なfeaturesリストでは「XならばY」という条件を表現できません。条件分岐(ステータスに応じた却下、抽出したフィールドに基づくルーティング、一致結果に応じたステップの制御)、Document AIのリクエストステップ、または終端の却下/判定ノードを使う場合、Diditのワークフローはノードグラフを使用します。これはコンソールのビジュアルビルダーが生成するものと同じ構造です。
グラフワークフローを最も簡単に構築する方法はDidit MCPです。エージェントに自然な言葉で依頼する(「本人確認の後、職業が’Software Engineer’に近ければ資金証明のステップを追加して」)と、グラフの構築、検証、保存までを代わりに行います。以下の構造は、これらのツール(およびコンソール)が生成するものです。

グラフの構造

グラフは{ start_node, nodes }です。nodesはノードIDからノードへのマップです。エッジは暗黙的に定義され、各ノードはnext(無条件)またはbranches[].goto(条件付き)、あるいはその両方で次のノードを指します。 start_nodeは機能ノードでなければなりません。分岐は順番に評価され、最初に一致したものが採用されます。空のrules: []はすべてに一致する「else」です(必ず最後に置いてください)。session_status: "Determine"は、各機能の結果を総合して自動的に判定します。
すべての分岐ノードには明示的なelse分岐が必要です。これはrules: []を持つ分岐で、どの条件にも一致しないセッションのルーティング先を指定します。分岐ノードのnextをフォールバックとして頼らないでください。単独のnextはビルダー上で曖昧なエッジとして表示され、見落としやすくなります。else分岐がなくnextを持つ分岐ノードを送信すると、APIがそのnextを明示的なelse分岐に変換します(つまり{ …, "branches": [<conditions>], "next": "liveness" }はbranches: [<conditions>, { "id": "else", "rules": [], "goto": "liveness" }]として保存されます)。明示性を保つため、else分岐は自分で作成してください。この変換はあくまで安全策であり、代わりになるものではありません。

分岐ルールと演算子

各ルールは、フィールドと値を演算子で比較します:
  • フィールドには、機能の結果(kyc.status、aml.status、document_ai.status、face_match.scoreなど)または抽出された値(kyc.full_name、kyc.age、kyc.nationality、kyc.extra_fields.profession、Document AIのフィールドdocument_ai.<key>、expected_details.*)を指定します。分岐が読み取れるのは、その分岐に到達するすべての経路で対応する機能が実行済みのフィールドのみです。
  • 演算子: equals、not_equals、greater_than(_or_equals)、less_than(_or_equals)、contains、not_contains、in、not_in、is_empty、is_not_empty、regex、およびfuzzy_match(文字列フィールドのみ。0–100のscoreが必須で、これは類似度のしきい値です。例: 職業が”Software Engineer”と80%以上類似)。

NFCが実行されなかった理由で分岐する

NFCノードの後では、nfc.skip_reasonをequalsまたはinと組み合わせて使い、チップの読み取りが行われなかった理由に応じてセッションをルーティングします。このフィールドは次の7つの固定値を取ります:
  • USER_SKIPPED
  • DOCUMENT_WITHOUT_CHIP
  • CHIP_CERTIFICATE_UNAVAILABLE
  • DEVICE_WITHOUT_NFC
  • INTEGRATION_WITHOUT_NFC_ACCESS
  • MRZ_KEY_UNAVAILABLE
  • JPKI_UNAVAILABLE
各値の意味はNFCのスキップ理由を参照してください。NFCが成功した場合、nfc.skip_reasonはnullになるため、スキップ理由に対するequalsルールもinルールも一致しません。 このフィールドは、ゲートによってスキップされたNFCノードでも値が決まります。これには、NFCのレポートや警告が存在しない場合や、allow_nfc_skipがfalseであっても書類またはデバイスのゲートによってNFCが実行されない場合が含まれます。そのため、nfc_verifications[]のエントリに頼らずにこれらのセッションをルーティングできます。
NFC対応状況が3値になる前に保存されたセッションでは、has_device_nfc_support: falseとなっている場合があります。そのため、古いWebセッションではINTEGRATION_WITHOUT_NFC_ACCESSではなくDEVICE_WITHOUT_NFCとして値が決まることがあります。
このグラフでは、ユーザーによるスキップにequalsを、ゲートまたは対応状況によるスキップにinを使い、NFCが成功した場合には明示的なelseを使用しています。分岐はNFCノードの後に置かれ、すべての遷移先は前方の終端ノードを指しています:
「既知のいずれかの理由でNFCが実行されなかった」ことを表すには、7つすべての値を指定してinを使用します。NFCが成功した場合(nfc.skip_reason: null)や、グラフがまだ認識していない将来の値に備えて、明示的なelse分岐を残しておいてください。

Document AI(例: 資金証明)

DOCUMENT_AI機能ノードは、1つ以上の書類をリクエストし、名前付きフィールドを抽出します:
設定した各フィールドは分岐に使える値document_ai.<key>となり、ステップの結果はdocument_ai.statusになります。 書類の名義人の氏名を保持するフィールドには"is_full_name": trueを設定します。抽出された値は検証済みの本人の氏名(OCR/本人確認で得た氏名、またはセッションの期待される詳細情報)と照合され、document_ai_name_match_score_thresholdを下回る不一致が生じた場合の処理はdocument_ai_name_mismatch_actionで決まります。このフラグは任意で、どのフィールドにも設定しない書類があっても構いません。また、設定できるのは書類1件につき最大1つのフィールドのみです。Document AIのすべての設定フィールドについては、ワークフロー機能の設定 → Document AIを参照してください。

エンドポイントとドラフトのライフサイクル

グラフの編集はアプリケーションごとに行い、コンソール/管理用エンドポイント(user-Bearerとread:workflows/write:workflows)を使用します。グラフを編集できるのはドラフトバージョンのみのため、ライフサイクルはドラフト作成 → グラフ設定 → 公開となります:

検証の警告

検証エンドポイントは{ "is_valid": true, "graph": …, "warnings": [] }を返します。警告は参考情報です。グラフは有効であり、警告があっても保存も公開もできます。各エントリには対象となる分岐ノードとアームが含まれるため、ビルダーは該当する条件を正確に示すことができます。
無効なグラフは400を返し、errorsおよびベストエフォートのwarningsリストを含みます。保存をブロックするのはerrorsのみです。

実践例: ソフトウェアエンジニアを資金証明にルーティングする

本人確認の後、結果が却下であればセッションを却下します。保有者の職業 ≈ “Software Engineer”(類似度≥80%)であれば、資金証明書類をリクエストします。その後、最終判定を行います。
最終ノードではsession_status: "Determine"を使用します。これはセッションで実際に実行された機能に基づいて自動的に判定(承認、却下、レビュー中)します。そのため、どの分岐もdocument_ai.status(Document AIをスキップするパスには存在しません)を読み取ることなく、資金証明のパスとelseのパスの両方が正しく判定されます。分岐が読み取れるのは、その分岐に到達するすべてのパスで機能が実行されたフィールドのみである点に注意してください。 これを{ "graph": <above> }として…/workflow-graph/エンドポイントに送信します(先に検証してください)。新規ワークフローを一から作成するにはMCPのdidit_workflow_set_graphを使用し、既存のワークフローを変更するにはdidit_workflow_edit_graphを使用します(小規模な操作で、既存のノードと許可リストを保持します)。Didit MCPを参照してください。

承認

x-api-key
string
header
必須

お客様のアプリケーションのAPIキーです。Business ConsoleのDevelopers -> API keysで取得できます。プライマリキーはフルアクセス権を持ちます。名前付きキーにはスコープを設定できます。リソースごとのアクセス権(なし、読み取り、書き込み)、一部のワークフローまたは承認済みセッションへの限定、IPアドレスのリストへの限定、有効期限の設定です。401は、キーが誤っている、失効している、または期限切れであることを意味します。403は、キーが送信されていない、キーにこのリソースやアクションへのアクセス権がない、またはIPリスト外のアドレスからリクエストが送信されたことを意味します。セッションのルートでの404は、セッションがキーのワークフローまたはステータスの対象外であることを意味します。メディアへのアクセス権がないキーでは、画像、動画、PDFのURLがnullで返されます。セッションの書き込み権限がないキーでは、セッションのリンクとトークンがnullで返されます。詳細は次を参照してください: https://docs.didit.me/console/api-keys

ボディ

application/json

シンプルな直線型ワークフローを作成します。APIはこの機能リストを内部でノードベースのワークフローグラフに変換します。フィールドは厳格なホワイトリスト方式です。ここに記載されていないキー(workflow_typeを含む)は400で拒否されます。

features
object[]
必須

実行順に並べた認証機能。APIは各項目を次の項目にリンクし、最後のステータスノードを1つ自動的に追加します。

Minimum array length: 1
workflow_label
string
デフォルト:ID Verification

ワークフローの表示名です(最大50文字)。省略した場合のデフォルトは"ID Verification"です。ワークフローを区別できるよう、必ず設定してください。

Maximum string length: 50
例:

"Standard KYC"

is_default
boolean

このワークフローを新しいセッションのデフォルトに設定します。

status
enum<string>

このフィールドを省略すると、セッションですぐに使える公開済みのワークフローが作成されます。公開せずに保存したい場合にのみdraftを使用してください。

利用可能なオプション:
draft,
published
is_white_label_enabled
boolean
デフォルト:false

このワークフローで作成されたセッションのホワイトラベルカスタマイズを有効にします。

is_desktop_allowed
boolean
デフォルト:false

デスクトップブラウザでの認証フローの実行を許可します。

max_retry_attempts
integer
デフォルト:3

認証が却下された後に許可される最大再試行回数です。0の場合、最初の却下でユーザーはブロックされます。

必須範囲: 0 <= x <= 10
retry_window_days
integer | null
デフォルト:7

再試行回数のカウントに使用する日単位のローリングウィンドウ。nullの場合は期間無制限の上限が適用されます。

必須範囲: 1 <= x <= 365
face_liveness_max_attempts
integer
デフォルト:3

セッション1件あたりのライブネス検知の最大送信回数です。デフォルトは3で、初回の試行1回と再試行2回です。機能レベルの設定で上書きされない限り、この値は生成されるライブネス検知および年齢推定のワークフローノードにもコピーされます。

必須範囲: 1 <= x <= 3
face_match_max_attempts
integer
デフォルト:3

セッション1件あたりの顔照合の最大送信回数です。デフォルトは3で、初回の試行1回と再試行2回です。機能レベルの設定で上書きされない限り、この値は生成される顔照合のワークフローノードにもコピーされます。

必須範囲: 1 <= x <= 3
session_expiration_time
integer
デフォルト:604800

未完了のセッションが期限切れになるまでの秒数。最小1時間(3600)、最大4週間(2419200)。

必須範囲: 3600 <= x <= 2419200

レスポンス

ワークフローが作成されました。レスポンスボディは簡易的な一覧項目ではなく、ワークフローの完全な設定です。これはGET /v3/workflows/{settings_uuid}/が返すものと同じ、生のVerificationSettingsのシリアライズ結果(約190フィールド: すべての機能のオン・オフ、しきい値、アクション、生成されたworkflow_graph)です。後続のセッション作成呼び出しで参照できるよう、uuid(workflow_idとしても公開)を保存してください。注意: featuresは" + "で連結された文字列で、料金はJSONの数値です。

以下のフィールドには型が定義されています。このオブジェクトには、ワークフロー設定のその他すべての列(機能の切り替え、しきい値、警告アクション、許可される書類、コールバック)も追加プロパティとして含まれます。workflow_typeに該当しないフィールドはnullです。

uuid
string<uuid>

バージョンごとの識別子(settings_uuid)です。ワークフローの各バージョンがそれぞれ固有の値を持ちます。

workflow_id
string<uuid>

ワークフローのすべてのバージョンで共有される不変の識別子。これを使って作成したセッションでは、公開済みの最新バージョンが使用されます。

workflow_label
string

ワークフローの表示名。

workflow_type
enum<string> | null

ワークフローテンプレート。テンプレートなしで作成されたグラフワークフローではnullです。

利用可能なオプション:
kyc,
kyb,
adaptive_age_verification,
biometric_authentication,
address_verification,
questionnaire_verification,
email_verification,
phone_verification,
null
is_default
boolean

アプリケーションのデフォルトのワークフローかどうか。

is_archived
boolean

アーカイブ済みのワークフローでは新しいセッションを開始できません。

version
integer

ワークフロー内のバージョン番号。

status
enum<string>

ドラフトバージョンは編集できます。公開済みバージョンは変更できず、新しいセッションで使用されます。

利用可能なオプション:
draft,
published
published_at
string<date-time> | null

このバージョンが公開された日時。下書きの場合はnullです。

is_simple_workflow
boolean

ワークフローにカスタムのworkflow_graphがない場合はtrueです。

is_editable
boolean

draftバージョンの場合のみtrueです。

workflow_url
string<uri>

このワークフローでセッションを開始する公開URLです。

workflow_graph
object | null

ワークフローのグラフ構造(ノードとエッジ)。シンプルなワークフローではnullです。

features
string

有効な機能を" + "で連結したものです。例: "OCR + LIVENESS"。

total_price
number | null

セッション1件あたりの料金。グラフ型ワークフローでは最も高い経路の料金です。

min_price
number | null

ワークフロー内で最も安い経路の料金。

max_price
number | null

ワークフロー内で最も高い経路の料金。

special_add_on_prices
object | null

組織固有のアドオン料金です。設定されていない場合はnullです。

max_retry_attempts
integer

認証が却下された後に許可される再試行回数。

retry_window_days
integer | null

再試行が許可される日数。

session_expiration_time
integer

未完了のセッションが期限切れになるまでの秒数。

questionnaire
object | null

ワークフローに紐づくアンケート、またはnullです。

kyb_role_settings
object[]

KYBの主要人物に対する役割ごとの検証設定です。

created_at
string<date-time>
updated_at
string<date-time>
signature_availability
object

現在署名に使用できる電子署名のレベル。signature_levelを設定する前に確認してください。kyc、kyb、グラフワークフローで返されます。

is_bank_verification_enabled
boolean

シンプルなKYCまたはKYBワークフローで銀行認証を実行するかどうかです。連絡先ステップ(および位置情報認証)の後、データベース検証、AML、IP分析の前に実行されます。銀行認証はまだ一般提供されていません。有効化されていない場合、オンにしようとしても拒否されます。

bank_verification_config
object

シンプルなワークフローの銀行口座認証設定です。BANK_VERIFICATIONノードと同じキー(例: bank_countries、bank_method_order)を受け付けます。不明なキーは破棄されます。すべてのキーは任意で、指定しないキーはデフォルト値のままとなるため、{}はすべてデフォルト値であることを意味します。詳細は銀行口座認証の設定を参照してください。

例:
is_geolocation_enabled
boolean

シンプルなKYCワークフローで位置情報認証を実行するかどうかです。連絡先ステップの後、銀行認証とデータベース検証の前に実行されます。企業(KYB)ワークフローでは実行できません。

geolocation_config
object

シンプルなワークフローの位置情報検証設定で、GEOLOCATIONノードと同じキー(例: is_geolocation_geofencing_enabledやgeolocation_max_attempts)を受け付けます。不明なキーは破棄されます。すべてのキーは任意で、指定しないキーはデフォルト値のままとなるため、{}はすべてデフォルト値を意味します。

例:
最終更新日 2026年11月1日