> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bilt.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments and credentials

> Base URLs, OAuth clients, API keys, and signing keys for each environment, and who provides what

Bilt issues credentials for each environment separately, and a credential from one environment fails in another.

## Environments

Test in staging first. Every call uses TLS 1.2 or later.

| Environment | Account links API | IdP issuer | Order reports |
| - | - | - | - |
| Production | `https://partnerapi.biltrewards.com` | `https://www.bilt.com/realms/BILT` | `https://webhooks.bilt.com` |
| Staging | `https://staging.partnerapi.biltrewards.com` | `https://staging.biltrewards.com/realms/BILT` | `https://webhooks.staging.bilt.dev` |
| Development | `https://dev.partnerapi.biltrewards.com` | `https://dev.biltrewards.com/realms/BILT` | Not available |

Bilt offers development access case by case. The account links API sends and returns JSON, except `204` responses, which have no body. The OAuth code exchange uses form data.

## Credentials

| Credential | Used for | Who creates it |
| - | - | - |
| IdP client | Minting member `id_token` values. Its `client_id` is the token audience. | Bilt |
| Partner client | Your access token for the account links API. | Bilt |
| API key | The legacy `x-api-key` header. It is being retired. | Bilt |
| Signing key pair | Signing order reports. Bilt returns a key ID for your `whpk_` public key. | You, or Bilt on request |
| Bearer credential | Bilt's calls to the endpoints you host. | You |

Treat every credential as a secret. Keys and clients are per environment.

## What Bilt gives you

* Two OAuth clients per environment: the IdP client and the partner client.
* An API key, which is being retired.
* A signing key ID for order reports, of the form `bk_<environment>_…`. It is not an account links credential.
* Confirmation of the environments you use.
* Your `partnerId` slug. It is informational, and no request sends it.

## What you give Bilt

* Redirect URIs for staging and production.
* The source IP ranges your account links calls come from, for Bilt's allowlist.
* Your `whpk_` signing public key, or a request for Bilt to generate the pair.
* The currencies you report in, and the tender types you accept.
* A technical contact and an escalation path, by email and Slack.
* The optional endpoints you plan to use, such as create and link.
* For the Bilt app flow: your base URLs, the [credential Bilt uses](#credentials-for-the-endpoints-you-host), how long you keep idempotency keys, and your normalization rules.

Your integration stays disabled until onboarding is complete. Until then, account links calls return `401` and order reports fail the signature check with `unknown_key`.

### Credentials for the endpoints you host

Bilt calls the endpoints you host with a credential you issue. During onboarding, tell your Bilt contact which scheme you support, and send the credential for each environment.

* Static bearer token: you issue one token per environment, and Bilt sends it as is.
* OAuth 2.0 client credentials: you give Bilt a client ID, a client secret, and your token URL. Bilt requests a token with the `client_credentials` grant and sends that token.

Whichever you choose, Bilt sends it as `Authorization: Bearer <token>` on every `/bilt/*` call. Each environment has its own credential, so a staging credential fails in production.

To rotate a credential, issue a new one and send it to Bilt. Once Bilt confirms the switch, revoke the old one.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.