Skip to main content
Carbon’s pipeline is built so that events are never duplicated and retries are always safe — from the SDK buffer to durable storage.

​
The path of an event

your app
  → SDK buffer (batched)
  → POST /v1/ingest-events (202 Accepted)
  → durable queue
  → idempotent processing
  → archive + analytics store
  1. The SDK buffers events and sends them in batches — by count, size, or age. See Configuration.
  2. The ingest API authenticates the batch, validates every event, attaches your space, and enriches provider and cost.
  3. Each event is placed on a durable queue and the API responds 202 Accepted.
  4. A worker processes each event exactly once in effect: the full event is archived, and a lean analytics row is written for querying.

​
202 means queued

The ingest API acknowledges once events are durably queued, not once they are written to the analytics store. Processing typically completes within seconds; events then appear in the dashboard.

​
Idempotency

Every event is identified by its client-generated id, unique within your space. The first event to arrive with a given ID wins; any later event with the same ID is acknowledged and discarded. This makes retries safe at every layer:
  • The SDK retries failed batches without creating duplicates.
  • Your own HTTP retries against the ingest API are safe as long as you reuse the same event id.
  • Internal queue redeliveries (processing is at-least-once) are deduplicated before storage.
If you implement your own delivery, generate the event id once when the call happens — not per send attempt — so retries deduplicate correctly.

​
Ordering

Events are timestamped by your application (startTimeMs, endTimeMs), so analytics are ordered by when calls actually happened, not by when events arrived. Late delivery — a retried batch, a flushed buffer from a recovered process — lands in the right place on the timeline.

​
Usage limits

Plan limits are enforced during processing, not at the API boundary. On the Free plan, events beyond the monthly allowance are rejected during processing and do not appear in the dashboard; on Plus, additional events are accepted and billed per event. See Plans and limits.