Meta CAPI Batching and Rate Limits: The Delivery Rules

Few delivery rules matter as much as Meta CAPI batching discipline: it is the difference between a delivery system and a delivery gamble: the Conversions API accepts several events in one request through its data array, which makes efficient delivery possible - and makes one bad event capable of failing everything around it. This guide covers the documented batching structure, the acceptance rules that decide whether a request survives, what a rejected batch means for retry logic, and the delivery discipline that keeps a busy funnel inside platform limits.

The per-event requirements - fields, identity, hashing - are the same whether an event travels alone or in a group, and they are documented in the complete Meta CAPI guide. This page is about the group itself.

The Data Array: Several Events, One Request

The Conversions API request carries an array - the data parameter - and each element is a complete event: its own event_name, event_time, event_id, user_data, and custom_data. Batching is structural, not a special mode: a single-event request is simply an array of one.

What the array changes is failure granularity. One request, many events - so the request's acceptance rules apply to the group. The most consequential of those rules is timing: event_time may sit at most seven days in the past, and a single stale event fails an entire request, processing none of its events (using the API). In a batch, one old record from a CRM re-import can hold a queue of fresh conversions hostage.

That risk is why batching discipline is a delivery-layer concern rather than a settings toggle: who enters the batch, and how old their timestamps are, decides whether the request lands.

Acceptance Rules the Batch Lives Under

Every event in the array keeps its own obligations:

1. Required fields per event. Website events need action_source, event_source_url, and client_user_agent; the fields are documented per event, not per request (Conversions API parameters).
2. Identity per event. Hashed contact data, fbp/fbc where they exist, and a stable event_id - each event carries its own matching material.
3. Timing for the group. The seven-day event_time rule is the batch-killer: the array survives only if every member does.

A useful mental model: the platform reads the array as a set of independent events sharing one envelope. The envelope is accepted or rejected as a whole - so the oldest, dirtiest event sets the bar for everything shipped with it.

When a Batch Fails: Retry Logic

A failed request tells you the batch contained a problem - the documented error surfaces point at which rule fired. Blind retry of the identical batch reproduces the identical failure. The documented-safe pattern:

1. Split the batch. Halve the array and retry the halves; the failing member isolates itself within a few rounds.
2. Fix or quarantine the member. A stale timestamp ages no better on retry - fix the source or drop the record to a quarantine queue (the delay mechanics cover how events get stale in the first place).
3. Redeliver the healthy remainder. The surviving events carry their own identities, so redelivery does not double-count them.
4. Feed the cause back. A recurring stale-event failure is an upstream problem - a CRM backfill or a tracker re-sync - and belongs in the troubleshooting checklist, not in retry loops.

Retry with backoff applies to transient transport failures; retry without inspection of a rejected batch just multiplies the rejection.

Delivery Discipline: Staying Inside Limits

Meta does not publish a numeric rate-limit table for Conversions API delivery in the batching guide, so the discipline is structural rather than numeric:

1. Batch by source timing, not by size ambition. Group events that naturally arrive together - a postback sweep, a CRM sync - rather than accumulating artificial mega-batches where one stale record holds fresh events hostage.
2. Keep identities stable across batches. Redelivery after a failure uses the same event_id values, so the platform's rules - not your retry - decide what counts.
3. Monitor both ends. The delivery layer's own logs show what was sent; Events Manager shows what arrived within its documented visibility window (get started). A widening gap between the two is the earliest throttling symptom.

The same monitoring-first approach that the delivery monitoring guide applies to outages applies here to throttling: measure the arrival gap, alert on its growth, and only then touch the batch shape.

Meta CAPI Batching: Frequently Asked Questions

Sources