For the complete documentation index, see llms.txt. This page is also available as Markdown.

πŸ”‘Authentication and environments

Send the widget public key in the Partner-Api-Key header on every White Label API request.

curl 'https://api.coindisco.com/api/white-label/v1/active-providers/' \
  --header 'Partner-Api-Key: pk_test_YOUR_PUBLIC_KEY'

HTTP header names are case-insensitive, but using the documented casing makes examples consistent.

Environment selection

The key identifies both the partner widget and its environment.

Prefix
Environment

pk_test_

Sandbox

pk_prod_

Production

Use resource IDs returned with the same key and environment. A provider, asset, network, or region ID from sandbox must not be assumed to have the same availability in production.

Browser and server usage

The value is a public widget key, not a private API secret. It is expected to appear in widget URLs. For a White Label integration, calling Coindisco through the partner backend is still recommended when the application needs centralized validation, logging, retry control, or protection from request manipulation.

Always use HTTPS and configure the widget's allowed origins in the dashboard.

Forwarding the end-user IP

When your backend calls Coindisco on behalf of a user, send the end user's real public IP address in the X-Forwarded-For header:

curl 'https://api.coindisco.com/api/white-label/v1/retrieve-buy-link/' \
  --request POST \
  --header 'Partner-Api-Key: pk_prod_YOUR_PUBLIC_KEY' \
  --header 'X-Forwarded-For: YOUR_END_USER_IP' \
  --header 'Content-Type: application/json' \
  --data '{ ... }'

Coindisco resolves the user IP from HTTP_X_FORWARDED_FOR first and falls back to REMOTE_ADDR. The resolved address is passed on to the provider, which uses it for geo availability, risk scoring, and β€” for some providers β€” as part of the signed checkout session.

In a server-to-server integration without this header, the provider receives your backend's IP instead of the user's. The transaction can then be rejected at the provider step, or the checkout link can fail with a signature or region error, even for users in supported regions. A backend hosted in a different country from your users makes this more likely.

Send the header on every user-initiated request, in both the buy and sell flows. Requests made directly from the user's device already carry the correct source address and need no extra header.

Last updated