Skip to main content
GET
Retrieve business verification

Authorizations

Authorization
string
header
required

Enter your API key in the format: sk_test_xxxxx or sk_live_xxxxx

Path Parameters

business_id
string
required
verification_id
string
required

Response

200 - application/json
verification_id
string<uuid>
required

Unique verification ID

Example:

"550e8400-e29b-41d4-a716-446655440000"

business_id
string
required

ID of the business entity created or verified

Example:

"bus_abc123"

status
enum<string>
required

Current status of the verification. Branch on this before reading risk or match:

  • completed — Terminal. Either a confident match (populated match, evaluated risk.level) OR a "no match" verdict (empty match: {}, risk.level: critical with "Business not found" reason).
  • in_progress — Not yet resolved. risk.level is null; match may be empty or partial — treat both as unset until terminal. Final outcome delivered via business.verification.completed webhook.
  • failed — Terminal. The verification could not be completed. Safe to retry.
Available options:
pending,
in_progress,
completed,
failed
Example:

"completed"

mode
enum<string>
required

Test/live partition the verification was created under. Determined by the API key used.

Available options:
test,
live
Example:

"live"

risk
object
required

Business risk assessment. Only meaningful when status: completed. See BusinessVerificationRisk.level for the three response shapes (matched / no-match / async-pending).

match
object
required

Field-level match results against the matched authoritative record. On a matched terminal, every submitted field is present with an explicit result (match, partial_match, no_match, or not_checked) — never omitted. partial_match marks genuine near-matches (name variation/DBA, ±1-day formation date, address containment); formatting differences (abbreviations, ZIP+4) normalize to match. Empty (or near-empty) in two cases: (1) terminal "no match" outcome (status: completed, risk.level: critical) where no record was identified — a submitted ein still reports not_checked; (2) async-pending outcome (status: in_progress) where verification hasn't resolved yet — wait for the webhook. Only fields the partner submitted in the request ever appear.

created_at
string<date-time>
required

ISO 8601 timestamp of when the verification was created

Example:

"2025-10-24T10:30:00Z"

reference_id
string

Your reference ID (if provided in request)

Example:

"biz_12345"

associates
object[]

Associated people verification results (full KYC results for each associate)

updated_at
string<date-time>

ISO 8601 timestamp of when the verification was last updated

Example:

"2025-10-24T10:35:00Z"