メインコンテンツへスキップ
サーバーSDKは、バックエンド向けのDidit公式ライブラリです。各SDKは、型付きのリクエストとレスポンスでAPIリファレンスのサーバーエンドポイントを呼び出し、Diditから送信されるWebhookを検証し、Didit Authenticationのトークンを確認します。Google Walletの2つのエンドポイント、Google Wallet検証の開始とウォレットレスポンスの送信は、まだどの1.0.1リリースにも含まれていません。Python、Node.js、Java、PHP、Ruby、.NETの各SDKには、それ以外のすべてのサーバーエンドポイントが含まれています。Go 1.0.1にはさらに9つのエンドポイントがなく、その大半はトラベルルールのエンドポイントです。Go SDKにまだないエンドポイントを参照してください。 DiditのAPIキーを保持するコードでは、どこでもサーバーSDKを使用します。たとえば、検証セッションの作成、判定の取得、スタンドアロンAPIの呼び出し、ユーザー・企業・ワークフロー・ケースの管理、取引とウォレットのスクリーニング、トラベルルールなどです。ブラウザやモバイルアプリでは、代わりにWebSDKとネイティブSDKを使用してください。これらはユーザーに検証フローを表示し、APIキーを保持することはありません。 APIリファレンスのサーバーエンドポイントのページ(データベース検証のサービスページを含む)には、cURLリクエストと並んで各サーバーSDKのコードサンプルが表示されます。サンプルが表示されるのは、そのSDKの最新リリースに、エンドポイントとサンプルが送信するすべてのフィールドが含まれている場合です。APIに追加されたエンドポイントやフィールドのサンプルは、各SDKの次回リリースで追加されます。1.0.1の生成後に追加されたvinやbank_account_numberなどデータベース検証の16個のリクエストフィールドは、どの1.0.1リリースにも含まれていないため、これらを送信するサービスページにはcURLのみが表示されます。

インストール

設定

すべてのSDKは同じ環境変数を読み込むため、オプションなしで作成したクライアントをそのまま使用できます。エッジランタイムにはプロセス環境がないため、APIキーをオプションとしてNode.jsクライアントに渡してください。 環境変数で設定できる項目はすべてクライアントにも渡せます。加えて、ベースURL、タイムアウト、再試行、デフォルトヘッダー、独自のHTTPクライアントも指定できます。クライアントはプロセスごとに1つ作成して共有してください。クライアントはコネクションプールを保持し、複数のスレッドやタスクから安全に使用できます。 accountメソッド(プログラムによる登録: 登録、サインイン、組織、アプリケーション)はhttps://apx.didit.me/auth/v2を呼び出し、APIキーを送信することはありません。account.loginでサインインし、返されたアクセストークンをアカウントトークンとしてクライアントに渡してください。

すべてのSDKに共通する機能

  • リソースとメソッド。 呼び出しはAPIのリソースに沿ってclient.<resource>.<method>(...)の形式で行います。たとえばsessions.create、sessions.retrieve_decision、transactions.createなどで、表記は各言語の命名規則に従います。パスのIDは位置引数で、ボディとクエリは1組の名前付きフィールドとして渡します。Python、Node.js、PHP、RubyはAPIのフィールド名(workflow_id)をそのまま使用し、Go、Java、.NETは各言語の命名規則(WorkflowID、workflowId、WorkflowId)を使用します。
  • リスト。 リストメソッドはすべての結果を自動でページングし(内部ではlimitとoffsetを使用)、各ページについてもcount、next、previous、resultsを提供します。Rubyではauto_paging_eachですべてのページを順に処理でき、ページのtotal_count、next_url、previous_urlはAPIのcount、next、previousに対応します。
  • ファイル。 アップロード(書類画像、セルフィー、住所証明、インポート)には、パス、バイト列、ストリームのいずれかを渡せます。ダウンロード(セッションのPDF、レポート)はバイト列またはストリームを返し、パース済みのJSONを返すことはありません。
  • 前方互換性。 SDKのバージョンがまだ認識しないレスポンスフィールドや列挙値は、エラーにはならず、保持されて読み取り可能です。そのため、APIに項目が追加されても、デプロイ済みの連携が壊れることはありません。
  • Webhook。 webhooks.verifyは、Webhookシークレットを使って配信のX-Signature-V2ヘッダーとX-Signatureヘッダー、およびタイムスタンプを確認し、型付きのイベントを返します。シークレットのローテーション中は、シークレットのリストを渡せます。署名方式についてはWebhookを参照してください。
  • 認証。 Authenticationヘルパーは、Authenticationの発行者が署名したアクセストークンとIDトークンを検証し、そのトークン、セッション、ステップアップの各エンドポイントを呼び出します。APIキーを使用することはありません。

エラー・再試行・タイムアウト

すべてのエラーはDiditErrorを継承します。Goでは、すべてのエラーがdidit.Errorインターフェースを実装し、*didit.NotFoundErrorのようなポインタ型になります。Java、PHP、.NETでは、各言語の慣例に従ってException接尾辞を付け、APIをApiと表記します(DiditException、ApiStatusException、NotFoundException)。 SDKは失敗したリクエストを最大2回再試行します。0.5秒から始まる指数バックオフ(フルジッター、最大8秒)を使用し、Retry-Afterに従います。GET、HEAD、PUT、DELETEは、接続エラー、タイムアウト、408、429、5xxの場合に再試行されます。POSTとPATCHは、429の場合、またはリクエスト送信前に接続が失敗した場合にのみ再試行されるため、再試行によって2件目のセッションや取引が作成されることはありません。デフォルトのタイムアウトは60秒です。すべてのレスポンスでは、生のHTTPステータス、ヘッダー、リクエストIDも参照できます。429の原因となる制限についてはレート制限を参照してください。

バージョニングとサポート

  • SDKはセマンティックバージョニングに従います。エンドポイントがAPIから削除された場合やメソッド名が変更された場合、旧メソッドは非推奨としてマークされたうえで少なくとももう1つ先のマイナーバージョンまで残るため、新しいメソッドへ移行する間もコードはビルドできます。
  • SDKは公開されているAPI仕様(openapi-25.jsonとopenapi-auth.json)から生成され、毎日その仕様を確認しているため、新しいエンドポイントやフィールドは7つすべてのSDKの通常リリースで提供されます。
  • 各SDKは、表に記載された最小ランタイムとそれ以降のすべてのリリースをサポートします。テストは最小ランタイムとそれ以降の各リリース(Node.jsとJavaでは各長期サポートリリース)で実行されます。
  • 各リポジトリのCHANGELOG.mdに、すべてのリリースの変更内容が記載されています。
  • セキュリティ上の問題は、SDKリポジトリのセキュリティアドバイザリーを通じて非公開で報告するか、support@didit.meまでご連絡ください。
最終更新日 2026年11月1日