Onboarding is done manually by the Proof team. There is no self-service signup.
What you send to Proof
Email the Proof team with the following:
| Field | Required | Description |
|---|
| Company / product name | Yes | For your partner record |
| Backend server IPs (production) | Yes | One or more IP addresses (or CIDR ranges) of your backend servers that will call the production Proof API. Used for the IP allowlist. |
| Backend server IPs (sandbox) | No | IP addresses for your sandbox / staging environment. Added to a separate allowlist for the sandbox base URL. |
| Contact email | Yes | For credential delivery and ongoing support |
| Off-ramp required | Yes | Whether your users need sell flow. Disabled by default. |
| Webhook URL | No | If you want Proof to forward transaction events server-to-server, provide a public HTTPS URL |
What Proof sends back
| Item | Description |
|---|
partner_id | Your unique partner identifier (for support tickets) |
client_token | Bearer token for every partner API request |
widget_id | Identifier passed to the widget at runtime |
| Base URL | Where to send your API requests |
Keep client_token secret. Treat it like a password.
Authentication
Every request to /widget/* and /ws must include:
Authorization: Bearer <client_token>
client_token is a server-side secret; exposing it in frontend code allows anyone to impersonate your integration.
Proof validates each request against the IP allowlist configured for your partner record. Requests from IPs not on your allowlist are rejected with 403 forbidden. Register all backend server IPs (or CIDR ranges) at onboarding; contact the Proof team to add or remove IPs after that.
Token rotation
To rotate your client_token, contact the Proof team. The Proof team will issue a new token and the old token will remain valid for a short grace period during the transition.
The internal signing secret used to compute session signatures is rotated by Proof on its own schedule. You never see it and never need to rotate it yourself. 
