> For the complete documentation index, see [llms.txt](https://coindisco.gitbook.io/coindisco/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://coindisco.gitbook.io/coindisco/business-integration-guide/business/overview-1/authentication-and-environments.md).

# Authentication and environments

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

```bash
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:

```bash
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.