event_id pattern.
How idempotency works
Every event accepts anevent_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
| Attempt | Delay before attempt |
|---|---|
| 1 | Immediate |
| 2 | 1 second |
| 3 | 2 seconds |
| 4 | 4 seconds |
| 5 | 8 seconds |
When to retry vs when to stop
| Status | Action |
|---|---|
| Network timeout / connection error | Retry with backoff |
429 Too Many Requests | Retry after the Retry-After header value (or 60 seconds) |
500, 502, 503, 504 | Retry with backoff |
400 Bad Request | Stop — fix the payload |
401 Unauthorized | Stop — check your API key |
403 Forbidden | Stop — check key/site_id match |
422 Unprocessable Entity | Stop — fix the field validation error |
Persisting event_id for critical events
For high-value conversions (purchases, subscriptions), generate and persist theevent_id before the network call — so you can retry even after a process restart: