API keys
The lifecycle of a Salyro key — issuing it, the rate limits attached to it, and revoking and replacing it without downtime.
A Salyro API key is what your code authenticates with. It is not a provider key: it is issued by a gateway, it identifies that gateway, and the provider credentials it reaches are the ones connected to that gateway.
Keeping the two apart is the point. Your provider keys stay where you put them and are never handed back out; the key your code carries is one you can issue and revoke as often as you like without touching a provider account.
Issued once, shown once
When a key is issued, the full value is displayed a single time. Salyro stores only a hash of it, so the value cannot be recovered afterwards — not from the dashboard, not from support, not from anywhere.
That is a consequence of how the key is stored rather than a limitation of the interface. A system that can show you a key again is a system that holds the key in a readable form, and that is the property being deliberately given up.
If you lose a key before saving it, issue another and revoke the first.
Bound to one gateway
A key belongs to the gateway that issued it and works only against that gateway. There is no key that spans gateways and no way to move one.
This is what makes gateway isolation operational: the key in your staging environment cannot reach production's provider credentials, and a key that leaks reaches one gateway's traffic rather than your account.
Rate limits
Each key carries a rate limit on how many requests it may make. Exceeding it causes requests to be rejected until the rate falls back within the limit — see Errors for how that failure differs from the others.
Revoking and replacing
Revocation is immediate and final. A revoked key stops working, and it cannot be restored — replacing it means issuing a new one.
Because revocation takes effect at once, the order matters when the key is in use:
Issue the replacement first
A gateway can hold more than one active key, so the new key can be issued and working before the old one is touched.
Deploy it
Update the environment that holds the key and confirm requests are succeeding with the new one.
Then revoke the old key
Once nothing is using it. Revoking first and deploying second is the same two steps in the order that produces an outage between them.
The exception is a key you believe is exposed. There, the outage is the cheaper of the two costs — revoke first and replace second. Respond to a leaked API key covers that case as a procedure.
Where not to keep one
A Salyro key carries the authority to spend against your provider accounts. Consumers of the Public API are server-side code, and the key should be handled accordingly:
- In a server-side environment variable or a secret store — not in source control
- Never in browser code, a mobile app, or anything else shipped to a user. A key in a client is a published key.
- One key per environment, so revoking one does not disturb the others