The short version
Treat every ThrottleProxy key as a workspace credential. Give each application or environment its own key so access can be traced and revoked cleanly.
01
Who can manage keys
Active Owners, Admins, and Developers can create and deactivate API keys in their authorized workspace. Billing, Viewer, suspended, and non-member accounts are denied server-side.
The active workspace is resolved from authenticated membership. Supplying another workspace or object identifier does not move the operation outside that boundary.
02
Use a name that explains ownership
Choose a key name that identifies the application and environment, such as checkout-worker-staging. Avoid names that reveal credentials, customer data, or incident details.
The full key is shown only when created. Later lists use a safe prefix rather than returning the secret again.
- Use separate keys for development, staging, and production-like traffic.
- Never paste a key into support email, screenshots, analytics, or source control.
- Store the value in the application’s approved secret manager.
03
Keep proxy and provider credentials separate
Authorization, x-api-key, cookies, ThrottleProxy-specific headers, and hop-by-hop headers from the inbound proxy request are removed before the outbound request.
Upstream provider credential storage is not connected. Do not put a provider secret into the ThrottleProxy key field or a setup-preview form.
04
Deactivate instead of sharing or reusing
Deactivate a key when a deployment, teammate, or trust boundary changes. Deactivation is workspace-scoped and invalidates the exact Redis configuration entry used by request authentication.
Create a replacement as a separate operation and update the intended application through its secret manager.
Before you move on
- Email is verified
- Key name identifies application and environment
- Raw value is copied once into approved secret storage
- No provider credential is mixed with the proxy key
- Old or exposed keys are deactivated promptly