Skip to main content
With headless KYB, your app’s server submits an organization’s verification data to Privy, and Privy forwards it to Bridge. No hosted Bridge link is involved, so your app owns the interface end to end. Use hosted KYB instead when Bridge should collect the business data and its owners’ documents. At a high level, headless KYB involves three steps:
1

Accept terms of service

An authorized representative accepts Bridge’s terms of service, which produces an agreement ID.
2

Submit verification data

Your app’s server submits the business data, its owners, and that agreement ID.
3

Track status

Bridge reviews the submission asynchronously. Your app polls status or consumes webhooks.
Before verifying organizations, register a Bridge API key with Privy and enable server-side flows for the environment the requests target.
Bridge reviews business customers manually, so KYB usually takes longer than KYC for an individual. Bridge may also require the organization’s associated persons to complete their own verification.

Accept terms of service

Bridge requires a signed terms of service agreement before it will create or update a customer. Generate an acceptance link with POST /v1/organizations/{organization_id}/kyb/tos, pass it to your frontend, and keep the agreement ID Bridge returns when the representative accepts. Pass that ID as client_agreement_id on the submission. Privy stores it, so later submissions for the same organization may omit it and Privy replays the stored one.

Submit verification data

Use the submit method from the kyb resource on organizations().
Unlike KYC, Privy does not fall back to a stored email for a business customer. Send email explicitly on the first submission.

Business data fields

data mirrors Bridge’s business customer payload. Values that Bridge defines, such as business_type and account_purpose, are passed through unchanged, so the Bridge customer API reference is the source of truth for accepted values.
Each address takes street_line_1 (at least 4 characters), street_line_2, city, subdivision (ISO 3166-2, required for US addresses), postal_code, and country (ISO 3166-1 alpha-3).

Associated persons

Each entry in associated_persons is a beneficial owner, control person, or signer. At least one of has_ownership, has_control, or is_signer must be true, and the business must have at least one control person and one signer.
Owners cannot be changed after the first submission; later submissions must omit associated_persons or repeat the existing owners.
Later submissions update the same Bridge customer. Omitted top-level fields are left untouched, including email; sending a different email replaces the address Bridge has on file, and since Bridge identifies customers by email, the old address stops resolving to this one. Nested objects such as an address are replaced whole. If a response never reached you, resubmit the identical data.
Bridge allows one customer per email address, across businesses and individuals alike. A submission whose email already has a Bridge customer returns 409 — Privy will not adopt an existing customer, since an email in a request body is not proof the organization owns it. Submit a different email, or contact [email protected] to link an existing Bridge customer to a Privy organization.

Next steps

Track KYB status

Poll an organization’s verification status or subscribe to webhooks

Headless KYC

Submit a user’s verification data from your server