One late event sinks the whole batch: the 7-day event_time limit in the Conversions API

The Conversions API lets you send several events in a single request: up to 1,000 in the data array. It’s handy for batch jobs, retry queues and CRM integrations. But every event carries an event_time, the moment it happened, and Meta limits how old it can be. One event over the limit is enough to lose the whole request.

What happens when an event is older than 7 days

The server sends a request with four events: a purchase from two hours ago, a lead from yesterday, an AddToCart from three days ago and a purchase from eight days ago that had been stuck in a queue. Meta answers with an error and processes none of the four, not even the three that were within the limit.

If nobody checks the API responses, the failure goes unnoticed. What shows up later are gaps: days with fewer conversions in Events Manager than orders in the backend, usually coinciding with a reprocessing run or the recovery after an outage.

Why Meta rejects the whole request

Meta’s documentation is explicit: event_time is a Unix timestamp in seconds, in GMT, and it can be up to 7 days before you send the event. If any event_time in data is more than 7 days in the past, Meta returns an error for the entire request and processes no events. The situations that cause it:

• Infrequent batches. A weekly job, or a daily one that piles up the weekend’s events, ends up mixing recent events with others that have already expired.
• Retry queues with no deadline. An event that failed days ago is retried again and again along with the new ones, and every time it sinks the whole batch.
• Imports from the CRM or the backend. Orders confirmed, refunds processed or leads qualified days after the original event are sent with their real date.
• event_time taken from the wrong field. For example, the customer’s sign-up date or the cart creation date instead of the moment of the conversion: the event looks much older than it is.

The same guide says that with other invalid events, valid events that carry an event_id are still stored. For the 7-day limit, though, the published rule is that no events are processed. Physical store events (action_source: physical_store) have their own guidance: upload them within 62 days of the conversion.

How to find batches rejected because of event_time

1. Review the logs of the API responses: a successful request returns no error; a rejected one does, with a message mentioning event_time.
2. For every send, compute the gap between the send time and the oldest event_time in the batch. Any value above 7 days is a lost batch.
3. In Events Manager, compare daily conversions with the backend orders and look for days with gaps, especially after reprocessing runs or outages.
4. In the event details, the Event Freshness tab shows the average delay between event_time and the send, on a scale from real time to weekly.

How to send events before they expire

• Send in real time, or close to it. Meta recommends sharing events as they happen or in batches close to real time, ideally within an hour.
• Filter before every request. Drop (and log separately) any event with an event_time older than 7 days. Leave a margin: if the batch takes a while to go out, an event that is 6 days and 23 hours old can expire on the way.
• Give retries a deadline. An event that couldn’t be sent within a few days should leave the queue, not keep dragging the rest down.
• Check the format. Seconds, not milliseconds, and in GMT.

Meta’s documentation: Server event parameters and Using the Conversions API.

How to check no batch gets lost

• API responses return no event_time errors and the number of events received matches the number sent.
• No batch contains events older than 7 days: the filter logs the ones it drops.
• In Events Manager, event freshness gets close to real time and daily conversions follow the backend orders again.

The events and dates in the example are illustrative. The error text in the animation is a paraphrase, not Meta’s literal message.