Server side only
A production key inside a web or mobile app is a public key: shipped code is readable, and minification is not encryption. Call the API from your server.
Developers
Authentication
How the quote endpoint is protected today, how keys will be issued, and the handling rules that avoid the classic outcome: a production key in a public repository.
Today
The quote endpoint is open and requires no key. The choice is defensible: a quote neither reads nor writes personal data, and an integration must be able to show a price before an account exists.
What is not in place yet
No rate limit is applied on this endpoint today. We would rather write that than display a quota table that is not enforced: the day the limit exists, it will be published here with its values, its response headers and the code returned when exceeded.
Keys, once they are issued
A key carries its environment in its prefix. A test key that worked in production would be a design flaw: it makes possible the real transfer you thought you were simulating.
Authorization: Bearer sk_live_9f2c4b1e8a7d3f60c5b2a1e9d8c7b6a5| Prefix | Environment | What it allows |
|---|---|---|
sk_test_ | Sandbox | Every operation, on simulated data. No real movement of funds, no call to a payment institution. Rail latencies are simulated so your tests meet the same waits as production. |
sk_live_ | Production | Real operations. Orders created with this key move money: it must never leave your server. |
whsec_ | Both | Webhook signing secret. It is never used to call the API: it only verifies that what you receive really comes from us. |
Handling rules
None of them is original. All of them are broken regularly, and that is how keys leak.
Never in a URL
As a query parameter, a key ends up in server logs, referrer headers and browser history. The Authorization header exists for this.
One key per integration
A key shared by three services cannot be revoked without breaking all three. One key per use makes revocation painless.
Immediate revocation on any doubt
A key pushed to a repository by mistake, even a private one, even deleted afterwards, is compromised: history keeps it and crawlers read public repositories within minutes.
Rotation without downtime
Two keys valid at once let you rotate with no window of unavailability.
- 1.Issue a second key. Both are valid at the same time.
- 2.Deploy the new key across your servers, one at a time.
- 3.Check that the new key is receiving traffic and the old one is not.
- 4.Revoke the old one. Revocation is immediate, with no grace period.
What we will never do
- We will never ask for your key by email, chat or phone. Support does not need it: it works with the key id, not the secret.
- We never display a secret key twice. It is visible at creation, then only its id and last four characters.
- We do not send keys by email. Email travels through, and is kept by, too many parties.