pinned.events

Developer documentation

Rate Limits

Understand 429 responses, Retry-After handling, and retry strategies for busy integrations.

Learn how Pinned Events API rate limits work, what 429 responses mean, and how to retry requests safely with backoff and idempotency.

What is rate limited

Public API routes have runtime rate limits to keep integrations predictable and protect the platform. API key creation is also limited for abuse prevention.

429 response

When a request is rate limited, the API returns 429 rate_limited. Honor Retry-After when present and use exponential backoff with jitter.

Rate-limit headers

Rate-limited responses include X-RateLimit-* headers and Retry-After when retry timing is available. Use Retry-After as the earliest retry time and add exponential backoff with jitter for repeated failures.

Backoff strategy

Use exponential backoff with jitter for repeated 429 or transient 5xx responses. Retry create-event requests with the same Idempotency-Key so a delayed retry cannot create duplicate event listings.

How idempotency helps with retries

For create-event requests, keep the same Idempotency-Key while retrying the same source event. This prevents duplicate event listings after a timeout or transient failure.

Related pages

Core resources