Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.proof.community/llms.txt

Use this file to discover all available pages before exploring further.

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:
FieldRequiredDescription
Company / product nameYesFor your partner record
Backend server IPs (production)YesOne 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)NoIP addresses for your sandbox / staging environment. Added to a separate allowlist for the sandbox base URL.
Contact emailYesFor credential delivery and ongoing support
Off-ramp requiredYesWhether your users need sell flow. Disabled by default.
Webhook URLNoIf you want Proof to forward transaction events server-to-server, provide a public HTTPS URL
The Proof team configures the rest — supported crypto currencies, destination wallets, widget defaults — based on what you need at onboarding. You do not send these as request parameters.

What Proof sends back

ItemDescription
partner_idYour unique partner identifier (for support tickets)
client_tokenBearer token for every partner API request
widget_idIdentifier passed to the widget at runtime
Base URLWhere 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>
All calls must originate from your backend server — never from the browser. The 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.