Bearer token for account links
This page covers how you authenticate to Bilt. For how Bilt authenticates to you, see Credentials for the endpoints you host.
- Send it as
Authorization: Bearer <token>, and on no other header. - Use the same partner client for every Bilt API, and never send a member access token.
401 with no detail. A sudden 401 means your credential was rotated or disabled, so contact Bilt. Bilt rotates keys with you, as a configuration change.
Create a link also requires the id_token as a second credential.
Legacy API key
Thex-api-key header is being retired. Do not send it with a bearer token. A rejected token does not fall back to the key.
Signatures for order reports
Order reports carry no token. You sign each request with your Ed25519 private key and send your key ID inX-Bilt-Key-Id. Your key identifies you, so no URL or body carries a partner ID, and partners never see each other’s orders. See Sign your requests.
Secrets on your server
- Use TLS 1.2 or later. Your redirect URI uses HTTPS. Plain
http://localhostis allowed only in development. - Keep secrets in a secret store. Cache your access token in memory, not on disk or in logs.
- Enforce
stateand PKCE withS256.stateblocks a forged callback. PKCE blocks an intercepted code, and the single-use code blocks replay.
Logging
Never logid_token values, access tokens, the Authorization header, authorization codes, client secrets, code_verifier values, API keys, or the bearer token Bilt sends you, or your whsk_ signing key.
You can log partnerUserId, your partner ID, and requestId. Keep personal data out of partnerUserId and your logs.