Managing the client ID and client secret
Every developer app gets a client ID, which identifies the app, and a client secret, which authenticates it. The client ID is safe to make public; the client secret must be treated like a password. This article covers where to find each, how to store them, what to do if a leak is suspected, and running several environments.
Where to find them
- Open "Developer apps" from the business account's menu and open the app.
- Under "Credentials", the client ID (a string starting with
app_) is always shown and can be copied. - The client secret (32 letters and digits) is shown once, right after the app is created and right after it is regenerated. ReceiptRoller stores only a hash of the secret, so it cannot be shown again later.
An app registered as a public client (mobile app) uses no secret and shows none. It authorizes with PKCE.
Client ID versus client secret
| Item | Client ID | Client secret |
|---|---|---|
| May be public | Yes | No |
| Role | Identifies the app (client_id on the authorize URL) | Authenticates the app (client_secret at the token endpoint) |
| In distributed apps or browser code | Fine | Never (server side only) |
| In URLs | Fine | Never (send it in the request body) |
Storage rules
- Keep it in environment variables or a secret manager (Azure Key Vault, AWS Secrets Manager and so on).
- Do not write it into source code, and keep it out of your Git repository.
- Use separate apps, and therefore separate secrets, for production, staging and development.
- Let only production services read the production secret.
- Do not include it in logs or error output.
If a leak is suspected
Regenerate the secret straight away. Only the business account's owner can regenerate it.
- On the app's details page, under "Credentials", press "Regenerate" and confirm.
- The new secret is shown once. Store it somewhere safe.
- The old secret stops working at once; there is no grace period. Put the new secret into your production configuration and deploy right away. Until you do, obtaining and refreshing tokens returns 401
invalid_client. - Regenerating does not revoke access tokens or refresh tokens already issued. If tokens may have leaked too, revoke them with
POST /api/v1/auth/revoke, or ask the owner of the connected business account to disconnect the app from "Connected apps".
Running several environments
Always register separate apps for production and development. An app holds one redirect URI, so environments with different URIs need separate apps anyway. Every client ID starts with app_, so put the environment in the app name to avoid mix-ups.
My App (prod)
→ Client ID: app_… (production)
→ Secret: the production secret manager
My App (dev)
→ Client ID: app_… (development)
→ Secret: environment variables in development