FIFO Delivery

FIFO (First-In, First-Out) delivery guarantees events are delivered in order, one at a time, per partition key.

When to use FIFO

State machines: status transitions must arrive in order
Financial transactions: debits before credits
User actions: create → update → delete must not reorder

Enable FIFO on an endpoint

curl -X POST https://app.mittr.io/api/v1/endpoints \
  -H "X-API-Key: mtr_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://api.example.com/webhooks",
    "eventTypes": ["order.*"],
    "fifo": true,
    "fifoPartitionKey": "$.data.orderId"
  }'

Partition keys

The fifoPartitionKey is a JSONPath expression evaluated against each event payload:

$.data.orderId — events for the same order delivered sequentially
$.data.customerId — events for the same customer delivered sequentially
Different partition keys are processed in parallel

Without a partition key, all events to that endpoint are strictly sequential (single partition).

How it works

Events are queued in a dedicated FIFO queue per endpoint
A FIFO worker dequeues one event per partition at a time
The event is delivered and acknowledged before the next is dequeued
If delivery fails, retries follow the endpoint’s retry policy
The partition is blocked until the failed event succeeds or is moved to dead letter

Trade-offs

	Standard delivery	FIFO delivery
Ordering	No guarantee	Strict per-partition
Throughput	High (parallel)	Lower (sequential)
Blocking	None	Head-of-line per partition
Use case	Notifications, alerts	State machines, transactions

Head-of-line blocking: A stuck event blocks its partition until it succeeds or goes to dead letter. Other partitions are unaffected.
Parallelism: Different partition keys process concurrently — only events within the same partition are sequential.