API Replay Plan

A practical example

Example: a CRM outage lasts four hours and your MAP queues 12,000 lead updates. The replay plan stores each failed event with its original timestamp and a unique event ID.

After recovery, events replay in chronological order, and the CRM's upsert behavior keyed on event ID prevents duplicate contact creation.

What to evaluate before investing

• Ask where failed events persist, for how long, and whether replay can be triggered manually or only automatically.
• Verify how duplicates are detected on the receiving side, such as idempotency keys or upsert behavior.
• Check whether replay preserves original event order and timestamps or rewrites them.

Limitations and tradeoffs

Replay depends on storage that many default connectors lack; without persisted failed events, an outage window is simply gone, and replaying stale events can overwrite newer data if ordering isn't controlled.