Most upstream APIs require credentials. Proceeds attaches those credentials to the proxied request on the server side, so your end users only see the Proceeds URL — never your bearer token, API key, or secret.Documentation Index
Fetch the complete documentation index at: https://docs.myproceeds.xyz/llms.txt
Use this file to discover all available pages before exploring further.
Pick an auth method
Configure auth at the service level. Every paywall in the service inherits it.| Method | When to use |
|---|---|
none | The upstream is fully public. |
bearer | The upstream expects Authorization: Bearer <token>. |
token | The upstream expects a static token in a header. |
x-api-key | The upstream expects X-API-Key: <key>. |
custom-header | Any other header pair. You provide the header name and value. |
query-param | The upstream reads the credential from the query string. |
bearer-customer | Bearer token plus a customer ID. |
x-api-key-secret | Two-part API key + secret pair. |
json-body-field | The upstream reads the credential from a JSON body field. |
What Proceeds collects
Depending on the method, Proceeds collects values such as:- Bearer token
- Token
- API key
- Header name and header value
- Parameter name and parameter value
- Customer ID
- API secret
- Field name and field value
Target URL — never returned to clients.
Change credentials
Editing auth on a service rotates the credentials Proceeds sends upstream on the next request. There’s no client-side change required.Next
Custom headers and query parameters
Forward extra headers or query params on a per-paywall basis.