Credential security

Your API key and secret identify your organisation and allow anyone who holds them to act as you. Protect them as you would any other production credential.

Rules

• Never place your API key, secret or token generation logic in browser code or in a mobile app. Anyone can inspect that code.
• Call getToken from your server only, and pass results to the browser only when you need to.
• Store the secret in a secrets manager or in protected environment configuration, not in source control.
• Use separate credentials for staging and production, and never reuse one in the other.
• Do not write keys, secrets or tokens to logs, support tickets or chat.
• Restrict who in your team can read production credentials.

The bearer token

The token is scoped to your publisher, not to an individual customer. Whoever holds it can call the API as your organisation until it expires, after ten hours. Cache it on your server and refresh it before expiry. getToken is limited to five requests per minute, so do not fetch one for every customer action.

Single sign-on links

For white-label publishers, the login link contains a per-customer token. It signs a person in, so treat it as a credential. Do not log it, email it or expose it in client-side code. Fetch it for each visit.

If a credential is exposed

Tell Spendstream straight away so that the credential can be replaced, and rotate any secret that may have been seen. Ask your Spendstream contact about the rotation process for your account.

Related pages

• Data handling
• Support responsibilities