Protect API Keys
Keep API keys in server-side secret storage. Do not put them in browser code, mobile app bundles, public repositories, URLs, or support messages. Use a separate key for each service so you can replace one without changing every integration. Choose the minimum scopes needed for your workload. Where practical, configure the key’s IP whitelist with your server’s public egress IP addresses. An empty whitelist allows requests from any IP that can otherwise authenticate.Rotate or Remove a Key
Use Regenerate in Settings > Developer to replace a secret. The old secret becomes invalid immediately, so update the service that uses it. The replacement secret is displayed only once. Use Delete to remove an unused or compromised key. If you need to move clients gradually, create a separate replacement key, update those clients, and then delete the old key.Request Limits
The Public REST API enforces a request limit and time window stored on each API key. These are per-key controls; do not infer a request allowance from a plan name or apply Custom REST integration quotas to the Public REST API. For requests that reach rate-limit checking, responses include:
When the limit is exceeded, the response is HTTP
429 with error code RATE_LIMIT_EXCEEDED and error.details.retryAfter in seconds. Respect the reported delay and use bounded retries with backoff. Check the result of a write request before retrying it; authentication does not imply that every write endpoint supports idempotent replay.