Skip to main content
Bridge requires a signed terms of service agreement before it will create or verify a customer. By default, the organization’s representative accepts Bridge’s terms on a Bridge-hosted page. With terms of service reliance, your app presents Bridge’s terms inside its own onboarding flow and records the representative’s acceptance. The representative never leaves your app, and Privy tells Bridge the agreement was signed.
Reliance does not remove the requirement that customers are shown Bridge’s terms of service. It only changes where those terms appear. Your app must display Bridge’s own terms and privacy policy, not a substitute of its own.

Get approved by Bridge

Bridge grants reliance per app, and only after reviewing the onboarding flow. Build the flow to the requirements below, then submit it for review. Until the app is approved, Bridge ignores client_agreement_id and still requires its own acceptance page. Bridge owns these requirements and may change them. Its terms of service reliance documentation is the authoritative reference. Display a checkbox alongside this exact text, with both documents linked:
By clicking “Accept”, you agree to Bridge’s [Terms of Service] and [Privacy Policy].
Link the terms and privacy policy for the region the organization is in. Bridge does not permit either document to be embedded inside another link.

Store an attestation for each acceptance

Record that the representative accepted, under an identifier your app can look up later. Bridge may send a list of identifiers and ask for the matching attestations at any time, so a random or non-durable value is not sufficient.

Submit the flow for review

Share a screenshot of the completed flow with your Bridge contact. Bridge submits it for review and approves reliance for the app.

Signal acceptance to Bridge

Once the app is approved, each representative still accepts Bridge’s terms in your app’s own flow. Pass the identifier for that organization’s stored attestation as client_agreement_id on the verification request, and Privy signals Bridge on your app’s behalf. client_agreement_id is an optional string between 1 and 1024 characters. It accompanies the verification request rather than a separate call, so there is no reliance-specific endpoint.
Include client_agreement_id when creating the KYB link. Bridge returns a link that goes straight to business verification, with no terms of service step.
On this path Privy sends Bridge only the fact of acceptance, as developer_accepted_tos. The identifier itself is not forwarded or stored. Omitting it produces a link that includes Bridge’s terms of service step.

Verify acceptance took effect

The verification response reports terms of service status under tos.status. When reliance applies, Bridge reports the requirement as satisfied and omits its own acceptance link.
A tos.status of pending after passing client_agreement_id means Bridge did not treat the terms of service requirement as satisfied, and still expects the representative to accept on Bridge’s own page. Confirm with Bridge that the app is approved for reliance.
Bridge’s sandbox accepts any agreement identifier, including identifiers it cannot resolve. Production rejects an unrecognized identifier and leaves the terms of service requirement outstanding, so a flow that works in sandbox can still fail in production. Verify tos.status against production before depending on reliance in a live integration.

Next steps

Hosted KYB

Send the organization through Bridge’s hosted verification flow

Headless KYB

Submit verification data from your server