Rate limits and retries

Handle authentication throttling and transient failures without duplicate imports.

Authentication attempts are protected by rate limits on IP and account subjects. The API does not publish a general requests per second quota; an absent quota is not a guarantee of unlimited capacity.

Honor throttling

When a request returns 429, wait at least the number of seconds in Retry-After. Do not immediately retry from another worker. Authentication infrastructure failures can return 503; treat them as temporary failures rather than changing working credentials.

Retry read requests

For timeouts, temporary network errors, and server errors, retry GET requests using bounded exponential backoff with jitter. For example, begin with one second, then two, four, and eight seconds, and stop after a reasonable number of attempts. Always honor a longer server supplied wait.

Do not automatically retry a wrong password, forbidden event, invalid identifier, or malformed input. Fix the request first. Use explicit client timeouts and log sanitized failure metadata.

Keep imports idempotent

Upsert by UUID and commit a synchronization checkpoint only after applying a complete successful response. A retry must not duplicate orders or attendees. Separate fetch retries from local processing errors.

Reduce unnecessary work

For writes, re-read the affected resource before retrying an uncertain result. There is no general idempotency-key contract; creation, visibility toggles and email operations can repeat their side effects. Read writing data for operation-specific success and retry rules.

Use snapshot validators, respect caching, and poll at a frequency that suits your workflow. Avoid many concurrent full history requests. Contact support when your data volume approaches the documented snapshot limits.