> ## Documentation Index
> Fetch the complete documentation index at: https://docs.privy.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Terms of service reliance
> Present Bridge's terms of service to an organization's representative inside your app's own onboarding flow
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](/kyc-kyb/kyb-tos).
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](https://apidocs.bridge.xyz/platform/customers/compliance/terms-of-service-reliance) documentation is the authoritative reference.
### Show Bridge's consent language
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.
| Region | Terms of service | Privacy policy |
| ------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| US | [Bridge Building Inc](https://www.bridge.xyz/legal/us-terms/bridge-building-inc) | [Bridge Building Inc](https://www.bridge.xyz/legal/us-privacy-policy/bridge-building-inc) |
| EEA | [Bridge Building sp. z o.o.](https://www.bridge.xyz/legal/eea-user-terms/bridge-building-sp-zoo) | [Bridge Building sp. z o.o.](https://www.bridge.xyz/legal/eea-privacy-policy/bridge-building-sp-zoo) |
| Rest of world | [Bridge Building Limited](https://www.bridge.xyz/legal/row-user-terms/bridge-building-limited) | [Bridge Building Limited](https://www.bridge.xyz/legal/row-privacy-policy/bridge-building-limited) |
### 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](/kyc-kyb/kyb). Bridge returns a link
that goes straight to business verification, with no terms of service step.
```ts {skip-check} theme={"system"}
const status = await privy.organizations().kyb.initiateLinks('', {
provider: 'bridge',
environment: 'sandbox',
email: 'finance@example.com',
client_agreement_id: ''
});
```
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.
Include `client_agreement_id` when [submitting verification data](/kyc-kyb/kyb-headless).
```ts {skip-check} theme={"system"}
const status = await privy.organizations().kyb.submit('', {
provider: 'bridge',
environment: 'sandbox',
client_agreement_id: '',
data: {
business_legal_name: 'Acme, Inc.'
// ...
}
});
```
On this path Privy forwards the identifier to Bridge as `signed_agreement_id`, alongside
`has_accepted_terms_of_service`. Privy stores it, so later submissions for the same organization
may omit it and Privy replays the stored one.
## 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.
```json theme={"system"}
{
"provider": "bridge",
"environment": "sandbox",
"status": "pending",
"tos": {
"status": "approved"
}
}
```
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
Send the organization through Bridge's hosted verification flow
Submit verification data from your server