Reliability
How retries, idempotency and errors work for the Event Stream.
Idempotency
Every event carries a unique_id you generate. Resending an event with the same unique_id is a no-op — duplicates are silently dropped. It's always safe to retry a batch on network errors or 5xx responses. Pick a unique_id that's stable per logical event:
bet-{round_id}/win-{round_id}A UUID generated at the source
Avoid timestamps or random IDs generated at retry time.
Timestamps
Use the time the event actually occurred, in UTC (ISO-8601). Not the time you sent the request accurate timestamps drive campaign logic.
Status codes
Status | Meaning | Action |
|---|---|---|
| Batch accepted, empty body. | Done. |
|
| Check the key. |
| A field failed validation. The body lists what. | Fix the payload, retry. |
| Some events couldn't be stored. The body lists | Retry the whole batch. |
If validation fails on any event (422), nothing in the batch is recorded — fix the payload and resend.
Batching
Up to 500 ms or 10,000 events per batch, whichever comes first. Mix any combination of event types. Order doesn't matter.
Different region? If your platform runs outside Unibo's primary region (Ireland), ask Unibo about a regional deployment for lower latency.
→ Full schemas and per-field reference: Consumer API →