認証アクティビティと、リリースに依存するそのWebhook配信については、認証イベントとWebhookで説明しています。一覧にない認証イベントタイプを、現行の送信先APIに登録しないでください。
概要
Webhookは、検証セッション、企業セッション、ベンダーユーザー、ベンダー企業、または取引の状態が変わるたびに、Didit がバックエンドへリアルタイムの更新をプッシュする仕組みです。1つ以上の送信先を必要なイベントに登録しておけば、結果が出た瞬間に対応できます。通常は、ユーザーがフローを完了してから数秒以内です。 Webhookは推奨される連携パターンです。GET /v3/session/{id}/decision/のポーリングもフォールバックとしてサポートしていますが、速度が遅く、リクエスト数が増えるうえ、data.updated、transaction.status.updated、エンティティレベルの変更など、Webhookでのみ送信されるイベントを取得できません。Webhook配信を信頼できる唯一の情報源として扱い、ポーリングはコールドスタート時または照合のためにのみ使用してください。
Didit Academyの連携レッスンのこのチャプターは、Webhookの概要から始まります。
連携に関するAcademyレッスンでは、3:12からWebhookを取り上げています。送信先の追加、イベントの選択、そして以下で検証する署名シークレットについて説明しています。
Cloudflare / WAFをご利用の場合。 Didit は、静的IPアドレス
18.203.201.92 からUser-Agent: DiditWebhook/2.0 +https://didit.meでWebhookを配信します。エッジで不明なクライアントをブロックしている場合は、Security > WAF > Tools > IP Access RulesでこのIPを許可し、受信側のホスト名に対して許可を選択してください。イベントタイプ
Webhookの送信先のsubscribed_events配列には、以下の値をそのまま指定してください。ワイルドカードはないため、受信したいイベントファミリーをすべて列挙する必要があります。また、イベントを複数の送信先に振り分けることもできます。
この表の値が購読可能なイベントのすべてです。
session.status.updatedやkyc.completedなどのイベントはありません。これ以外にDiditが行う配信は、署名なしのkyb.registry_search.resolvedコールバックのみです。このコールバックはPOST /v3/kyb/search/にリクエストごとに渡すwebhook_urlに送られ、送信先に送られることはありません。
ペイロードの構造
エンベロープ
すべてのWebhookは同じエンベロープを共有します。フィールドは常にsort_keys=Trueとコンパクトな区切り文字(, / :)でシリアライズされます。そのため、同じペイロードから送信側と受信側の双方で同じ署名が再現されます。
セッションイベント(通常のセッションおよび企業セッションの
status.updatedとdata.updated)では、エンベロープに以下のフィールドも含まれます。
セッションエンベロープの例
V3の複数形の配列 (重要)
decision内では、機能ごとの結果はすべて複数形の配列になっています。そのため、1つのワークフローに同じ機能の複数のインスタンスを含めることができます(例: 複数の書類にわたる複数のID確認)。
node_idと、機能ごとのstatusが含まれます。従来のV2の単数形フィールド(id_verification、nfc、liveness、face_match、phone、email、poa、aml、ip_analysis、database_validation)は読み取らないでください。これらは、送信先が明示的にwebhook_version: "v2"に固定されている場合にのみ表示されます。
電子署名の結果はsignatures[]に含まれ、ワークフローに電子署名ステップがある場合にのみ存在します。署名者ごとに1件の要素があり、署名者、コード確認、証明書、タイムスタンプ、各書類のハッシュとダウンロードパス、エビデンスPDFが含まれます。署名専用のイベントはありません。読み取るタイミングはstatus.updatedで判断してください。電子署名レポートを参照してください。
銀行口座確認の結果はbank_verifications[]に含まれ、銀行口座確認ステップごとに1件の要素があります。各要素のmethodは口座の確認方法を示し、open_banking(銀行へのサインイン)、account_lookup(口座チェック)、またはフォールバックとしてのstatementかmicrodepositsのいずれかで、口座が評価されるまではnullです。本人がContinue without your bankを選択した場合、continued_without_bankはtrueとなり、continuationにその理由が示されます。この場合、methodはnoneになります。ただし、それ以前に試行が評価されていた場合は除きます。本人が銀行口座を確認できない場合を参照してください。口座チェックで確認された口座では財務データは読み取られないため、ステップで要求された残高、取引、収入はfinancial_data.not_collectedに列挙されます。銀行口座確認の方法を参照してください。
Investigator ブロック
ユーザーセッションまたは企業セッションの V3decision には investigator も含まれます。これはそのセッションの最新のInvestigatorレビューで、一度もレビューが行われていない場合は null です。
書類収集系の機能(KYB書類とDocument AI)には専用の複数形配列はありません。これらは判定の
features[] リストに { "feature": "DOCUMENT_AI", "node_id": "…" } として表示されます(ノードごとに1エントリ)。詳しくはDocument AIを参照してください。
ユーザー認証の判定には、単一の biometric_consent オブジェクトも含まれます。これは、セッションで生体認証への明示的な同意が必要だったかどうか、trigger、回答の status とその証跡を示します。status: "pending" かつ reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK" の場合、4.10.0未満のネイティブSDKが同意ステップなしで顔を撮影したことを意味します。詳しくは生体認証の同意を参照してください。
本人確認方法のキー
すべてのid_verifications[] 項目には、その項目を生成した本人確認方法が示されます。そのため、ハンドラーは実際に得られた証跡に応じて処理を分岐できます。
既存のハンドラーは変更なしでそのまま動作します。書類によるセッションでは
verification_method が document に設定され、その他は null のままです。フィールドごとの型はデータモデルにあります。
承認済みのウォレットセッション (status.updated)
エンティティイベントのペイロード
ACTIVE、FLAGGED、BLOCKED のいずれかです。user.data.updated と business.data.updated は status フィールドを保持したうえで、changed_fields 配列と { field: { previous, current } } 形式の changes マップを追加します。business.* イベントでは vendor_user_id の代わりに vendor_business_id を使用します。
取引イベントのペイロード
取引のWebhookは同じファンアウト基盤で配信され、同じエンベロープを使用しますが、セッションではなく取引を識別します。action_required は null、または必要なユーザーアクションで説明している保留中のユーザーアクション(type が wallet_ownership または verification_session で、その url を含む)です。
新しい取引のデフォルトは APPROVED です。作成中にルール、ブロックリスト、またはワークフローがステータスを変更した場合、最初の transaction.created ペイロードにはその最終ステータスが反映されます。transaction.status.updated は同じ形式で、更新後の status を含みます。取引のステータスは APPROVED、IN_REVIEW、DECLINED、AWAITING_USER のいずれかです。severity は UNKNOWN / LOW / MEDIUM / HIGH / CRITICAL、direction は INBOUND / OUTBOUND です。transaction.created と transaction.status.updated は本番環境のアプリケーションに対してのみ配信されます。サンドボックスでのトラベルルールのやり取りでは、environment: sandbox 付きで travel_rule.status.updated が送信されます。
KYB登記検索のコールバック
非同期のPOST /v3/kyb/search/フローでは、送信先イベントではない追加のペイロードが1つ配信されます。検索リクエストに webhook_url を渡すと、登記の照会が完了した時点で、Didit がその URL に kyb.registry_search.resolved コールバックを POST します。このコールバックは、送信先Webhookと次の3点で異なります。
- 署名なしです。
X-Signature*ヘッダーはありません。代わりに Didit はX-Didit-Unsigned-Callback: trueを付与します。検証するには、request_idを検索リクエストが返したIDと照合してください。 - イベント名は
event_typeに入り(webhook_typeではありません)、application_idとenvironmentはありません。 timestampとcreated_atはエポック整数です。これは他のWebhookと同じですが、検索エンドポイントのISO形式のcreated_atとは異なります。
timestamp が付け直され、署名なしのままです)。候補リストの完全なスキーマについてはKYB Registry APIを参照してください。
署名検証
すべてのWebhookは、送信先のsecret_shared_keyを使ってHMAC-SHA256で署名されます。3種類の署名ヘッダーが送信されるため、お使いのスタックで損なわれずに届くものを選べます:
Diditが常に送信するヘッダー:
送信先の署名シークレットがローテーションされてから24時間は、配信に
X-Signature-Previous、X-Signature-V2-Previous、X-Signature-Simple-Previousも付与されます(署名シークレットのローテーションを参照)。
署名シークレットのローテーション
送信先の署名シークレットはBusiness Consoleでローテーションします。 ローテーション後24時間は、その送信先へのすべての配信に、置き換えられたシークレットで作成された3つの追加ヘッダーが付与されます:
署名ヘッダーとその
-Previousヘッダーのどちらかが一致すれば受け入れるハンドラーであれば、新しいシークレットをデプロイしている間も検証を継続できます。古いシークレットは-Previousヘッダーと一致し、新しいシークレットは通常のヘッダーと一致するためです。
以下のコードサンプルはこの処理を行っています。
24時間を過ぎると新しいシークレットでしか検証できなくなるため、24時間以内に新しいシークレットをデプロイしてください。
GET /v3/webhook/destinations/{destination_uuid}/のprevious_secret_expires_atで、24時間が終了する時刻を確認できます。
再試行と再送は、送信時点の送信先の現在のシークレットで改めて署名され、-Previousヘッダーが付与されるのは24時間の間だけです。
24時間以内に再度ローテーションすると、最も古いシークレットは即座に無効になります。新しいローテーションの直前まで現在のシークレットだったものだけが、新しいローテーションから24時間、-Previousヘッダーで検証され続けます。
-PreviousヘッダーはWebhookの送信先にのみ存在します。
レガシーのwebhook_urlに署名するアプリケーションレベルのsecret_shared_keyには重複期間がありません。PATCH /v3/webhook/のrotate_secret_keyでローテーションすると、古いシークレットは即座に無効になります。
X-Signature-Simpleは非推奨
これは互換性上の制約であり、その場で修正できるものではありません。4フィールドの正規化文字列は通信上の取り決めです。X-Signature-Simpleを検証するすべての受信側はまさにこの4フィールドを再計算するため、ヘッダーの署名対象を変更すると、署名検証時にすべての受信側で気付かないうちに動作しなくなります。また、ボディを署名対象にするには、双方がバイト単位で再現できるJSONの正規形式を定める必要がありますが、DiditはすでにそれをX-Signature-V2として提供しています。独自の正規化ルールを持つ、ボディを対象とする2つ目の方式を追加するのではなく、このヘッダーは現状のまま維持し、ペイロード全体を対象とする既存の方式を推奨して非推奨としています。
利用者への影響:
- ワイヤー上の変更はありません。
X-Signature-Simpleは引き続きすべての配信で、同じ方法で計算されて送信されます。既存の検証処理はそのまま動作し、削除する場合は十分前もってお知らせします。 - 新規の連携では
X-Signature-V2を使用する必要があります。 ミドルウェア耐性があり、かつペイロード全体を対象とします。 X-Signature-Simpleから移行できない場合は、それを検証したうえで、Webhookのボディから読み取るのではなくAPIからレコードを取得してください。
3つの方式がある理由
一部のWebフレームワーク(Expressのボディパーサー、Djangoのミドルウェア、APIゲートウェイ)は、ハンドラーが読み取る前にJSONを暗黙的に再エンコードします。元のボディに"José"が含まれていて、ミドルウェアがそれを"José"に書き換えると、データは同一でもバイト列が変わります。その結果、X-Signatureは失敗します。X-Signature-V2は、ほぼすべてのミドルウェアが決定的に再現できる正規化JSON形式(キーのソート、コンパクトな区切り文字、エスケープしないUnicode)から計算されます。そして、それでも検証に失敗する場合に備えて、非推奨のX-Signature-Simpleは、パーサーに依存しない短い文字列だけに署名する方式にフォールバックします。署名するのはその短い文字列だけでボディには一切署名しないため、ボディの正当性は保証できません。
推奨される検証順序
- まず
X-Signature-V2を試します。JSON.parse(body)をキーをソートし、Unicodeを保持したまま再エンコードしてからHMAC-SHA256(secret, canonical)を計算し、ヘッダーとtimingSafeEqualで比較します。 - V2が失敗し、生のバイト列を読み取れる場合は、
HMAC-SHA256(secret, rawBody)に対してX-Signatureを試します。 - 両方とも失敗した場合に限り、非推奨の
X-Signature-Simpleにフォールバックし、HMAC-SHA256(secret, "{timestamp}:{session_id}:{status}:{webhook_type}")と照合します。この方法で認証されるのはエンベロープのみです。本文のdecisionは信頼できないものとして扱い、それに基づいて処理を行う前にGET /v3/session/{session_id}/decision/から再取得してください。
-Previousヘッダーが存在する場合は、どちらのヘッダーとの一致も受け入れてください(署名シークレットのローテーションを参照)。
いずれの場合も、リプレイ攻撃を防ぐため、5分より古いリクエスト(abs(now - X-Timestamp) > 300)は拒否してください。
再試行ポリシー
エンドポイントが5xxまたは404を返した場合、Diditは指数バックオフで最大2回再試行します。
- 1回目の再試行: 最初の失敗から約1分後。
- 2回目の再試行: 1回目の再試行から約4分後。
attempt番号が付きます。イベントの初回配信は1で、再試行または再送のたびに、繰り返す元の試行の番号に1を加えた値になります。
自動再試行は、その後に送信先のurlを変更した場合でも、初回の試行を送信したURLに送られます。
手動の再送は送信先の現在のURLに送られるため、URLを修正すれば再送も正しく届きます。
その他に知っておくべき配信ルール:
- 送信HTTPリクエストは5秒でタイムアウトします。
- DiditはSSRF対策として、プライベートURLやlocalhostのURLへの配信をブロックし、リダイレクトには一切従いません。直接応答する公開HTTPSエンドポイントを使用してください。
- 生のバックスラッシュ、制御文字、またはオーソリティ部に複数の
@を含む送信先urlは、不正な形式として拒否されます。このようなURLは作成できず、既存のものも再配信やリプレイができません。ユーザー情報部分が最大1つのシンプルなhttps://host/path形式のURLを使用してください(Basic認証形式のWebhook URLの場合)。 2xxは成功として扱われます。タイムアウトと接続失敗は再試行の対象になります(配信ログには504/503として表示されます)。404以外の3xxおよび4xxレスポンスは再試行されません。- 再試行時、Diditは新しい
X-Timestampで署名を再計算するため、タイムスタンプと署名の組み合わせは常に一致します。 - 再試行と再送には、送信時点での送信先の現在の署名シークレットで署名が付与されます。
配信順序
DiditはWebhookが届く順序を保証しません。 各配信は個別にキューに入れられ、再試行は初回の試行から数分後に届くため、Approvedのstatus.updatedが、それより前のIn Progressのものより先に届くことがあります。
受信側はこれを前提に構築してください。
- Webhookは何かが変更されたことを示すシグナルとして扱ってください。順序が重要な場合は、
GET /v3/session/{session_id}/decision/を呼び出し、現在のstatusに基づいて処理してください。 - 古いイベントで新しい状態を上書きしないでください。イベントの
created_atを、そのレコードについて最後に保存したものと比較し、古いイベントは無視してください。 - 重複の判定には
event_idをキーとして使用してください。この値は再試行の間も変わりません。
送信先の設定
送信先はBusiness Console > API & WebhooksまたはManagement APIから管理できます。1
送信先を作成する
POST /v3/webhook/destinations/を呼び出し(またはコンソールで宛先を追加をクリックし)、label、公開url、webhook_version("v3")、およびこのエンドポイントが受信すべきすべてのイベントファミリーを含むsubscribed_events配列を指定します。イベントは少なくとも1つ必要で、ワイルドカードはありません。2
secret_shared_keyを保存する
作成時のレスポンスで送信先の
secret_shared_keyが返されます。他のサーバーシークレットと一緒に保存してください。これはこの送信先専用のもので、3種類すべてのHMAC-SHA256署名の入力になります。GET /v3/webhook/destinations/{destination_uuid}/は、APIキーを使う呼び出し元と、Webhookの閲覧権限を持つコンソールユーザーにこの値を再度返します。3
エンドポイントを実装する
公開のHTTPS
POSTルートを用意し、生のリクエスト本文を読み取り、署名を検証し(X-Signature-V2を優先)、タイムスタンプの許容範囲を確認してから、webhook_typeに応じて処理を振り分けます。処理をキューに入れたらすぐに2xxを返し、重い処理は非同期で行ってください。4
受信を確認する
送信先のDeliveriesタブを確認します。正常なWebhookは1〜2秒以内に
200を返します。5xx/404はDiditの再試行ポリシーのトリガーとなり、失敗が続く場合は2回目の再試行の後に破棄されます。5
Try Webhookで繰り返し確認する
本番環境のトラフィックを有効にする前に、コンソールのTry Webhookシナリオを使って、承認済み、却下、レビュー中、KYB、エンティティ、アクティビティ、取引のペイロードでエンドポイントを検証してください。

本番稼働前に、Business Consoleから直接テストWebhookを送信してエンドポイントを検証できます。
コードサンプル
Webhookエンドポイントのセキュリティを確保するため、送信先のsecret_shared_keyを使って受信したリクエストの真正性を検証してください。
Node.js / Express (推奨: X-Signature-V2)
X-Signatureバリアントも同様に機能しますが、こちらは生の本文に署名します。網羅性のため、下のレガシーセクションに掲載しています。
Python / FastAPI (推奨: X-Signature-V2)
PHP / Laravel (推奨: X-Signature-V2)
PHPのJSONのデフォルト設定では、正規形を再現できません。4つの設定を上書きする必要があり、1つでも漏れると署名対象のバイト列が変わり、ダイジェストが一致しなくなります。
最も問題になりやすいのは空オブジェクトの落とし穴です。Diditのペイロードには
risk_view.countries.risk_scores、risk_view.crimes.risk_scores、risk_view.custom_listなどの空のマップが日常的に含まれるため、連想配列を経由して変換すると、まれなエッジケースではなく通常の承認済みセッションで署名が壊れます。
- PHPでは、整数値の浮動小数点数に特別な処理は不要です。 Diditはこれらを整数としてシリアライズし(
100.0→100)、PHPのjson_encodeも整数値の浮動小数点数を同じ形式で出力するため、上のNode.jsサンプルとは異なりshortenFloatsステップは必要ありません。 serialize_precisionは-1のままにしてください(PHP 7.1以降のデフォルト)。ホスト環境でこれが17に上書きされていると、json_encodeは87.42を87.420000000000002として出力し、すべてのX-Signature-V2の検証が失敗します。
verifySignatureRawがより簡単な代替手段です。Laravelの$request->getContent()は未加工のバイト列を返すため、PHPの手前で本文を再エンコードするものがない限り、X-Signatureは機能します。そうした再エンコードこそX-Signature-V2が耐えられるように設計されたケースであり、V2を最初に試すのはそのためです。
テスト
エンドポイントの動作確認のために、完全な認証を実行する必要はありません。- Business Console > API & Webhooks > Try Webhookからシナリオ(例:
approved_full_features、declined_face_mismatch、in_review_aml_hit、business_session_approved、transaction_created、activity_created、user_status_updated)を選択し、必要な情報をすべて含むWebhookを送信先URLに送信します。 - すべてのシナリオは本番環境のトラフィックと同じ3つの署名ヘッダーと正規エンコーディングで署名されており、Unicodeのテストデータ(
approved_kyc_with_unicode)も含まれているため、ミドルウェアを経由してもX-Signature-V2が機能することを確認できます。テスト配信にはサンプルデータが含まれ、追加のX-Didit-Test-Webhook: trueヘッダー(およびUser-Agentの(Test)サフィックス)が付与されるため、本番環境の状態から除外できます。 - リグレッションをデバッグする必要がある場合は、送信先のDeliveriesタブから過去の任意の配信を再送できます。
例
承認済みのKYCセッション (status.updated)
警告付きの却下セッション (status.updated)
承認済みの企業セッション (status.updated, KYB)
作成された取引 (transaction.created)
トラベルルールの交換ステータス変更 (travel_rule.status.updated)
travel_rule_statusには、トラベルルールに記載されている13種類の交換ステータスのいずれかが入ります。
railはINTERNAL、TRP、GTR、TRUST、VERIFYVASP、SYGNA、EMAILのいずれか(レールが選択されるまでは空文字列で、レールを特定できなかった場合と、サンライズ登録では常に空文字列です)、またはDidit Test VASPが応答したサンドボックス送金の場合はTEST_VASPです。directionはINBOUNDまたはOUTBOUNDです。
サンドボックスのイベントには"environment": "sandbox"が含まれ、TEST_VASPイベントにはさらにtest_vasp: trueとtest_vasp_scenario(応答したシナリオ)が含まれます。
Diditがトラベルルール送金のために取引を作成する場合(POST /v3/transactions/の呼び出し、入金後のサンライズ登録、インバウンドのTRP照会、またはINTERNALレールのインバウンド側)、まずその取引のtransaction.createdイベントを送信し、その後に送金のtravel_rule.status.updatedイベントを送信します。
そのステップ中に取引のステータスを変更するルールがある場合は、transaction.createdより前にtransaction.status.updatedが送信されることもあります。また、すでに作成済みの入金取引に紐づくサンライズ登録では、transaction.createdは送信されません。
各Webhookは個別に配信・再試行されるため、再試行されたイベントが後続のイベントより後に届くことがあります。ハンドラーはtransaction_idをキーにし、現在の状態が必要な場合は取引を再取得してください。
TRUST経由で送信された送金にはCOMPLETEDイベントが届きません。TRUSTはDiditが読み取れる応答を何も返さないためです。送金は確認期限までAWAITING_COUNTERPARTYのままとなり、その後EXPIREDで終了します。GTR、VerifyVASP、Sygna Bridgeでは、Diditがネットワークから取引相手の応答を読み取り、イベントはそれに従います(トラベルルールのネットワークを参照)。
ワークフローのコンプライアンス変更 (workflow.compliance_changed)
transition.fromとtransition.toは、compliant、gaps_detected、pending_change、unknown_coverage、not_evaluatedのいずれかです。
severityは、ギャップが検出された場合はactionable、保留中の変更の場合はindicative、ギャップが解消された場合はinformativeです。
Diditは、変更があったワークフローごとに1件のイベントを送信します。
作成された取引ルールの提案 (transaction_rule_suggestions.created)
kindは、新しいルールの場合はADD、既存ルールの変更の場合はTWEAK、ルールを無効化する場合はDISABLEです。ADDの場合、rule_idはnullです。
open_countは、実行後も未対応のまま残っている提案の数で、新しい提案も含みます。
このWebhookのオン・オフはルール提案の設定で切り替えます。取引のWebhookを参照してください。
Investigatorイベント (investigator.*)
12種類のinvestigator.*イベントは、他のすべてのイベントと同じエンベロープ(event_id、webhook_type、timestamp、created_at、application_id、environment)と同じ署名ヘッダーを使用します。含まれるのはIDと数値のみで、名前、レビュアーが入力した理由、説明文、エンドユーザーが記述した内容は一切含まれません。session_idはなく、対象のアイテムはitemで示されます。
provenanceは、どのバージョンのInvestigatorがレポートを作成したかを示します。
engineはInvestigatorエンジンのバージョンで、8文字の不透明なIDです。エンジンが変更されるたびに変わるため、engineが同じ2つのレポートは同じエンジンによって作成されたものです。agent_versionはエージェントのバージョンです。policy_versionは、レポートが従ったお客様自身のポリシーのバージョンです。model_idは非推奨のエイリアスで、engineと同じ値が入ります。代わりにengineを参照してください。prompt_hashは送信されなくなりました。
item.kindはアイテムの種類(セッション、企業セッション、取引、ケース)を、item.idはそのIDを示します。_atで終わるタイムスタンプはISO 8601形式の文字列です。他のイベントと同様に、subscribed_eventsに正確な文字列を列挙してこれらのイベントを購読します。
ユーザーエンティティのステータス変更 (user.status.updated)
再提出されたセッション
レガシー: 生のボディを使うX-Signature
X-Signatureは現在もすべての配信で送信されます。これはDiditが送信する正確なバイト列(json.dumps(..., sort_keys=True, separators=(",", ":")))に対するHMAC-SHA256です。ミドルウェアがボディを変更する前に生のボディを読み取れる場合にのみ使用してください。
- Node.js
- Python
レガシー: V2 Webhook形式
機能ごとのオブジェクト自体は両バージョンで同じです。V2の送信先は、V3と同じくヒットごとの
match_score、risk_score、score_breakdown、risk_view、review_statusと、集計値のscoreをそのまま受け取ります(AMLレポートを参照)。V2に固定すると、decision内でAMLレポートが置かれる場所が変わりますが、その内容は変わりません。
下流のコンシューマーがまだV2形式を必要とする場合は、webhook_version: "v2"に固定した別の送信先を作成し、新しいコンシューマーはV3のままにしてください。
関連ページ
- Webhook送信先API: 送信先の一覧取得、作成、更新、削除と、配信ログの確認。
- Webhook送信先の作成: 送信先の
secret_shared_keyを含むリクエスト/レスポンスのスキーマ。 - データモデル:
decisionに埋め込まれる機能ごとのすべてのオブジェクトの正式なスキーマ。 - 判定スキーマ: セッションのWebhookに埋め込まれる
decisionオブジェクトの全フィールド一覧。 - 認証ステータス: 上記で参照されている正確な
statusの値と遷移。 - レート制限: フォールバックとして
GET /v3/session/{id}/decision/をポーリングする際に適用される制限。