Credential vault¶
Save a target's auth once, then reuse it across as many targets as you like — instead of pasting the same bearer token or API key into every target that needs it.
Save a credential¶
- Open Credentials in the project menu.
- Give it a name (e.g. "Stripe production key") and pick an auth type:
| Type | What you enter |
|---|---|
| Bearer token | A single token, sent as Authorization: Bearer <token> |
| Basic auth | A username and password |
| API key (header) | A header name and a key value, e.g. X-Api-Key: <key> |
| API key (query param) | A query parameter name and a key value, e.g. ?api_key=<key> |
| Public/private key | A secret and a key, sent as Secret: <secret> + Key: <key> |
- Save. The credential is now available to reference from any target in this project.
Reference it from a target¶
When editing a target, tick Use a saved credential instead of entering auth here and pick it from the dropdown. The target now uses that credential — edit the credential once and every target referencing it picks up the change automatically.
You can still enter auth directly on a target instead, if you'd rather not reuse it anywhere.
Editing and deleting¶
- Editing: you can change a credential's name and auth type at any time. If you leave a secret field blank while editing, the existing value is kept — you don't need to re-enter it just to rename a credential. (We can't show you the current value to confirm it either way — see the security note below.)
- Deleting: a credential still referenced by one or more targets can't be deleted — repoint or remove those targets first. This is a deliberate guard: deleting a credential out from under a live target would silently break delivery to it.
Security — read this precisely¶
The value you enter is sealed using asymmetric cryptography specific to your project — the panel that saves it and the relay's request-handling tier are never able to decrypt it back. Delivering to your target uses a short-lived authorization tied to the specific encrypted value(s) it covers, usable only a limited number of times to allow for delivery retries, and expiring with the request — rather than the credential itself, so it can't be replayed against a different target or reused indefinitely.
Your credential is not stored in plaintext and is not casually recoverable by the parts of our system that handle your requests day to day. We stop short of calling this "zero-knowledge" — recovering a credential is possible under deliberate, targeted access to specific internal infrastructure, not through routine access to the database or the request-handling tier.
Client certificates (mTLS) aren't covered by the credential vault yet — those are set up separately.
Questions about how this works? [email protected].