Theme
Reliability
The contract at the edge: batches are validated per event, so one malformed event does not lose the other 999, and the response names each refusal by index with every reason. Delivery is at-least-once with server-side de-duplication on a client-generated messageId, so retrying is always safe. An event accepted at the edge that the pipeline later cannot store is quarantined in failed_events with its stage and reason and kept 30 days — nothing is silently dropped.
What the SDKs add on top: bounded queues, batching, byte-bounded POSTs, retry with exponential backoff and jitter, and a drop once the retry budget is exhausted rather than retrying forever.
What survives a restart differs, and it matters. The browser queue is in localStorage and is restored on the next load. Swift persists to disk. Android can, but its default storage is in-memory and loses everything unless you pass a storage implementation. Node, Python, Java and Go hold the queue in memory: a hard kill loses it.
Only Python honours a Retry-After header. Node, Java and Go explicitly ignore it.
See the support matrix for the full grid.
Per-SDK reference
Each page's §14 covers batching, retries, what survives a reload or restart, and what is best-effort. §15 on each page is a symptom-to-cause troubleshooting table.
React: see Browser §14.