The API applies limits per key. Most authenticated routes allow 600 requests per minute. Searches and guest-message delivery have tighter limits because they represent different workloads. Do not design a polling loop around the general limit alone.
Know the narrower buckets
Waiver search, participant search and check-in candidate search are limited to 60 requests per minute. Confirmation sending, event invitation sending and individual invitation resending also use a 60-per-minute limit. Webhook test requests are limited to 10 per minute.
Unauthenticated traffic is limited by IP. Adding more anonymous retries does not help a failed credential become valid. Diagnose 401 and 403 responses before considering traffic behavior.
Use the response headers
Inspect x-ratelimit-limit and x-ratelimit-remaining. When a request returns 429, use the retry-after value in seconds to decide when to try again. Keep the affected job queued rather than repeatedly sending the same request while the limit is exhausted.
Coordinate workers that share one key. Ten independent workers each making a reasonable number of calls can still exhaust their shared allowance. A central queue or limiter makes the real request rate visible.
Reduce work before adding retries
Debounce participant search at the desk, especially when staff type one character at a time. Use webhook events to learn about changes instead of continuously scanning all signed records. Follow pagination when a list operation supports it, and save progress between pages.
Do not turn a rate-limited messaging action into a duplicate send. A request that was clearly rejected with 429 differs from a connection timeout with an uncertain outcome. Keep those cases separate in your queue.
Observe the complete job
Record the route, response status, request ID and wait time. Alert on repeated exhaustion that leaves work unfinished, not on one successfully recovered 429. Review limits together with error recovery before launching a high-volume import or event invitation process.