Environments and credentials

Two records, one project

environment is sandbox or production, and it is a property of the application record, not a header or a query parameter. The production record is created separately and carries its own client id. Configuration does not flow between them: a redirect URI added to sandbox is not a redirect URI on production.

Some things are read across the pair. The go-live checklist looks at the sandbox record for the recent sign-in, and at the production record for everything else. The quickstart endpoint always answers about the sandbox sibling, whichever record you ask about.

Client secrets

A client secret carries a prefix that says which environment it belongs to, so a leaked one is recognisable to secret-scanning programmes:

Secrets are issued on the application's Credentials screen (/applications/<applicationId>/credentials). The screen sends POST /v1/developer/applications/{applicationId}/credentials/oauth-client-secret with a body: name is required (up to 100 characters, so you can tell two secrets apart in the list later), and overlapHours is optional — 1 to 72, 24 when omitted — and is explained below.

POST /v1/developer/applications/{applicationId}/credentials/oauth-client-secret
content-type: application/json

{ "name": "Checkout service, October" }

The screen lists what exists from GET …/credentials and revokes one with DELETE …/credentials/oauth-client-secret/{credentialId}. Rotation is: issue the new secret beside the old one, deploy it, then revoke the old one. Two rules shape that:

• At most two secrets are active at once. Issuing a third is refused with ACTIVE_CREDENTIAL_LIMIT_REACHED until you revoke one.
• The old secret is revoked for you after the overlap. When a second secret is issued beside an existing one, the existing one is scheduled for automatic revocation overlapHours later — 24 hours unless you chose otherwise. The response says so (overlapHours, and overlapEndsAt in the activity record). Deploy the new secret inside that window, or token exchanges with the old one start failing when it closes.

Public or confidential

There is no setting for this. An application starts public, and issuing its first client secret makes it confidential — the quickstart endpoint reports which. The token endpoint accepts client_secret_basic, client_secret_post and none, so a public client authenticates with PKCE alone.

PKCE is S256 and nothing else, and it is required of both: a confidential client sends code_challenge at authorize and code_verifier at token exactly as a public one does. A client secret authenticates the application; it never replaces PKCE, and a code issued without a challenge is not redeemable.