KYB法人登記API：企業の検索と選択

エンドポイントと請求

有料の企業データソースを使用したスタンドアロン検索が成功すると、候補の件数にかかわらずリクエスト1件あたり$0.50の料金がかかります。結果が空の場合、検索が失敗した場合、および他のソースのみから結果が返された場合は課金されません。その後のプロファイル取得は別途請求されます。取得は3つのデータレベルで提供され、レベルごとに1つのエンドポイントがあり、料金は国ごとに設定されています（国別の料金）。

エンドポイント	取得できる内容	料金
`POST /v3/kyb/search/`	候補企業：名称、登記番号、ステータス、種類	有料ソースの結果が返された場合に$0.50
`POST /v3/kyb/select/`	Lite：企業プロファイル（識別子、ステータス、法的形態、設立日、登記住所、事業内容、連絡先情報）と役員	Lite料金：国により$2.00-$3.00
`POST /v3/kyb/shareholders/`	Liteに加えて、直接の株主とその所有比率の区分	Shareholders料金：国により$5.00-$22.00
`POST /v3/kyb/ubo/`	Shareholdersに加えて、所有構造の連鎖をたどって特定された最終的な実質的支配者	UBO料金：国により$9.00-$96.00

selectはLiteレベルです。ホスト型のKYBワークフローがLiteレベルの登記チェックに対して請求するものであり、従来どおりの仕様を維持します。Europeとは、EEA、英国、スイスを指します。 ShareholdersまたはUBOの検索では、そのレベルに対応する所有構造のソースに問い合わせます。そのソースが当該企業のデータを保持していないと回答した場合、検索はその国の他の登記ソースにも問い合わせます。これにより、所有構造のソースに掲載されていない企業も、手動入力に移行することなく候補として提示されます。この方法で見つかった候補は、リクエストしたレベルを維持します。取得時には所有構造のソースに再度問い合わせが行われ、それでも当該企業のデータが保持されていない場合は、Liteプロファイルが提供・請求され、registry_ownership_status: "not_held"が付与されます。

提供されたレベルの料金をお支払いいただきます。 すべてのレスポンスにはregistry_tier_requestedとregistry_tier_deliveredが含まれます。その国の登記機関が所有構造のデータを保持していない場合、または選択した企業について登記機関に所有構造の記録がない場合、所有構造のリクエストは利用可能な最上位のレベル（通常はLite）として提供・請求され、その理由がregistry_ownership_statusに示されます。UBOリクエストで、解決後のレポートに実質的支配者として自然人が1人も記載されていない場合は、Shareholdersとして提供・請求されます。

バージョニング。 ShareholdersとUBOのエンドポイントは/v3/にのみ存在します。スタンドアロン検索の料金は/v2/kyb/search/にも適用されます。プロファイル取得は別途請求されます。

所有構造のステータス

registry_ownership_statusは、ShareholdersまたはUBOのリクエストのうち、所有構造部分がどうなったかを示します。

値	意味
`not_requested`	Liteでの取得だったため、所有構造は要求されていません。
`delivered`	レジストリが所有構造データを提供しました。`registry_tier_delivered`に示されるレベルが請求の対象です。
`not_held`	所有構造のレジストリは応答しましたが、この企業を掲載していないため、提供できる所有構造の記録がありません。この企業は、その国の別のレジストリソースで見つかったものです。代わりにLiteプロファイルが提供・請求され、`registry_data.ownership_error: "company_not_found"`が返されます。
`unavailable`	その他の理由で所有構造データが提供されませんでした。レジストリが保持する記録に所有者の記載がない、レジストリが所有構造セクションをまったく返さなかった、またはレジストリに問い合わせできなかった、のいずれかです。どれに該当するかは`registry_data.ownership_error`に示されます。代わりにLiteプロファイルが提供・請求されます。
`pending`	所有構造セクションはまだレジストリから取得されていません。取得されるまでは何も請求されず、`registry_tier_delivered`は`null`です。

not_heldとunavailableはいずれもLiteとして提供・請求されますが、同じ結果ではありません。not_heldは所有構造のソースがその企業をカバーしていないこと、つまりカバレッジの欠落を意味します。一方unavailableはデータが提供されなかったこと、つまり障害、またはレジストリが空のまま返したセクションを意味します。理由はregistry_data.ownership_errorに示されます。以前は所有構造のレジストリが企業を掲載していないためにunavailableを返していた選択は、現在はnot_heldを返します。ステータスで分岐している場合は、どちらも同じLiteの提供として扱ってください。この理由の値のうち、次の2つは意味が異なり、同じ結果として解釈してはなりません。

`ownership_error`	意味
`no_owners_on_record`	レジストリは所有構造セクションに応答しましたが、所有者の記載がありません。その企業は、そのレジストリに株主名簿を登録していません。
`ownership_section_unavailable`	レジストリが所有構造セクションを返さなかったため、そのセクションについては何も提供されていません。リストは空なのではなく欠落しています。企業の所有者については何も示していません。

レジストリが返さなかったセクションは、構造化された形でもregistry_data.section_errorsに記録されます。セクション(officers、shareholders、group_structure)をキーとし、レジストリが応答したステータスが格納されます。

{
  "section_errors": {
    "shareholders": {
      "status_code": 404
    }
  }
}

section_errorsは、手元にあるレスポンスの状態を表すもので、それまでの経緯を表すものではありません。最初のリクエストでは返されず、後の処理で提供されたセクション(下記の非同期取得を参照)は、そのエントリが削除されます。そのためregistry_ownership_status、ownership_error、section_errorsは常に一致します。deliveredのセクションにエントリが存在することはなく、no_owners_on_recordにshareholdersのエントリが伴うこともありません。また、セクションが部分的に提供されることもありません。レジストリがリストの最初のページを提供した後に以降のページの提供に失敗した場合、その試行では取得は完了しません(pendingの取得は次の処理で再試行され、新しいリクエストにはレジストリ利用不可のエラーが返されます)。したがって、提供されたofficersや株主のリストは、常にレジストリが保持するリスト全体です。section_errorsに記載されたセクションは、空の結果ではなく、提供されなかったデータとして扱ってください。section_errorsにエントリがあるのにofficersや株主のリストが空であっても、その企業については何も示していません。

所有構造の非同期取得

一部のレジストリはオンデマンドで照会されます。そのソースに対してまだ照会されたことのない企業に対する最初のリクエストでは、取得中のため所有構造セクションが返されず、データは数分以内に届きます。これを「所有構造の記録なし」として報告すると、実際には株主がいる企業を過小に示すことになるため、リクエストは代わりにpendingとして返されます。取得がpendingの間は、fetch_statusもpendingとなり、レスポンスのステータスは202 Acceptedです。Diditはこのセクションを自動的に再試行し、追加のリクエストを行うことなく取得を完了します。

所有構造データが届くと、保存されたチェックに株主と実質的支配者が表示され、registry_tier_deliveredは提供されたレベルになり、そのレベルで利用料金が請求されます。
再試行期間の終了時点でもセクションが空の場合、ステータスはunavailableとなり、リクエストはLiteとして提供・請求されます。

request_idを保持し、registry_checks[0].company.fetch_statusがresolvedになるまでGET /v3/session/{request_id}/decision/をポーリングしてください。pendingの間は取得リクエストを繰り返さないでください。新しいPOSTはそれぞれ別個のリクエストとして、個別に請求されます。候補企業を探すにはPOST /v3/kyb/search/を使用します。検索では保存されたチェックは作成されません。検索のtier入力によって、検索対象のチェーンが決まります。詳しくは検索のレベルを参照してください。レジストリの検索には90秒ほどかかることがあります。Diditにすぐ応答を返させ、候補の準備ができた時点で指定のURLに通知させたい場合は、webhook_urlを送信してください。この軽量な通知のための検索コールバックには意図的に署名が付与されていないため、共有シークレットを設定する必要はありません。返されたkyb_response_idを使い、POST /v3/kyb/select/、POST /v3/kyb/shareholders/、またはPOST /v3/kyb/ubo/で必要なレベルのプロファイルを取得します。取得は請求の対象となり、結果はBusiness ConsoleにManual Checkとして保存されます。

一般的な流れ

購入する予定のtierで、会社名、登記番号、国を指定して検索します(basicがデフォルトのLiteチェーンで、shareholdersとuboはそれぞれのレベルのチェーンを検索します)。
search_resolved=falseの場合は、ポーリングせずにオプションのwebhook_urlコールバックを待ちます。
返された候補をオペレーターまたは顧客に表示します。
該当するkyb_response_idを必要なレベルで取得します（Lite の場合は select、shareholders、または ubo を選択します）。
返されたrequest_idを保存し、保存された法人確認の結果を取得する際に使用します。

検索コールバック

プロバイダーが検索の完了をDiditに通知すると、Didit はお客様の webhook_url に POST を1回送信します。

{
  "event_id": "7f5a1c93-6a44-4f0e-9f2b-3d8a1c6f2e91",
  "event_type": "kyb.registry_search.resolved",
  "request_id": "b5ef9df5-bd9e-4d61-bbe5-5eb7a8fb6f85",
  "vendor_data": "business-123",
  "metadata": {
    "source": "onboarding"
  },
  "search_status": "resolved",
  "search_resolved": true,
  "kyb_registry": {
    "companies": [
      {
        "kyb_response_id": "kyb_resp_123",
        "name": "TESCO PLC",
        "registration_number": "00445790",
        "status": "active",
        "type": "Public Limited Company",
        "registered_address": "Tesco House, Shire Park, Kestrel Way, Welwyn Garden City, AL7 1GA",
        "risk_level": null,
        "fetch_status": "pending"
      }
    ],
    "pagination": {
      "total": 1,
      "page": 1,
      "per_page": 25
    },
    "search_status": "resolved",
    "search_resolved": true
  },
  "timestamp": 1767225600,
  "created_at": 1767225600
}

このコールバックは配信通知として扱ってください。返された kyb_response_id を POST /v3/kyb/select/、POST /v3/kyb/shareholders/、または POST /v3/kyb/ubo/ で使用して、課金対象となる法人登記プロファイルの取得を実行します。

最終更新日 2026年11月1日

​エンドポイントと請求

​所有構造のステータス

​所有構造の非同期取得

​一般的な流れ

​検索コールバック

エンドポイントと請求

所有構造のステータス

所有構造の非同期取得

一般的な流れ

検索コールバック