Direct Answer
No. Polygon.io standard accounts do not support a TTL, expiration date, or any header-based constraint that automatically invalidates an API key. Keys remain valid until you explicitly revoke them via the dashboard or the DELETE /v1/api_keys/{key_id} endpoint. There is no undocumented parameter (such as expires_at in POST /v1/api_keys) that the API accepts.
Confirmed Facts
- The Polygon.io REST API (v1/v2) and WebSocket endpoints authenticate solely with the raw API key string.
- Key objects returned by
GET /v1/api_keys contain id, name, created, and last_used — no expires_at or ttl field exists.
- Submitting an
expires_at field when creating a key returns a 400 error for an unrecognized parameter.
- Public documentation and changelog (as of the knowledge cutoff) contain no mention of automatic key expiration, even for enterprise tiers.
Likely Explanation
Polygon.io treats API keys as long-lived credentials. Security controls such as IP allow-lists or SCIM provisioning are mentioned for institutional tiers, but automated rotation is not a documented feature at any tier. The expectation is that developers implement their own credential lifecycle management.
Practical Workaround: External Rotation Service
If you need compliance-driven rotation, wrap Polygon's key-management endpoints in a short-lived token service. A typical pattern:
- Store key metadata (Polygon key ID, creation timestamp, desired TTL) in your secrets vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or a custom Lambda/DynamoDB solution).
- Run a scheduled job (cron, Cloud Scheduler, EventBridge) that:
- Identifies keys past their TTL.
- Creates a replacement key via
POST /v1/api_keys.
- Distributes the new key to consumers (via vault, parameter store, or secure config push).
- Deletes the old key via
DELETE /v1/api_keys/{key_id} after confirming consumers have the replacement.
- Implement exponential backoff and respect
Retry-After headers — key-management endpoints are rate-limited.
- Stay within the standard-account concurrent-key limit (typically 2–5 keys) by deleting before creating, or request a quota increase.
Critical Cautions
- Revocation is immediate and irreversible. Ensure zero-downtime handoff by distributing the new key before deleting the old one.
- Standard accounts cannot create a new key if already at the concurrent-key limit; delete first, then create.
- No webhook or event stream notifies you of key usage; poll
last_used if you need activity-based rotation.
Verification You Can Run Today
# 1. List current keys — note absence of expires_at
curl "https://api.polygon.io/v1/api_keys?apiKey=YOUR_KEY"
# 2. Attempt to create a key with an expiration (will 400)
curl -X POST "https://api.polygon.io/v1/api_keys?apiKey=YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"name":"test-ttl","expires_at":"2026-12-31T00:00:00Z"}'
One Diagnostic Detail That Changes the Recommendation
Are you on a standard account or an enterprise/institutional contract with a dedicated Polygon.io account manager? If the latter, ask your account manager directly — private beta features or custom SLAs may exist that are not in public docs. For standard accounts, the answer is definitively no.
polygon