Skip to main content
Network failures and temporary server errors happen. The server events API is designed to handle retries safely — as long as you follow the event_id pattern.

How idempotency works

Every event accepts an event_id field. When the same event_id arrives more than once, the pipeline marks the second occurrence as a duplicate and excludes it from analytics. Your conversion counts stay accurate even if you retry a request multiple times. The rule: generate the event_id once, before your first attempt, and reuse the same value for every retry of that event.

Implementation pattern

Retry schedule

AttemptDelay before attempt
1Immediate
21 second
32 seconds
44 seconds
58 seconds
Cap your delay at 30–60 seconds. After 5 failed attempts, log the event and alert — do not retry indefinitely.

When to retry vs when to stop

StatusAction
Network timeout / connection errorRetry with backoff
429 Too Many RequestsRetry after the Retry-After header value (or 60 seconds)
500, 502, 503, 504Retry with backoff
400 Bad RequestStop — fix the payload
401 UnauthorizedStop — check your API key
403 ForbiddenStop — check key/site_id match
422 Unprocessable EntityStop — fix the field validation error

Persisting event_id for critical events

For high-value conversions (purchases, subscriptions), generate and persist the event_id before the network call — so you can retry even after a process restart: