Error Handling
Part of Marketing automation error handling
Retrying a failed integration without duplicate sends
Check the original outcome, retry the unfinished action and use a stable send identity to reduce duplicate messages during integration recovery.
Before retrying an integration, check whether the original attempt produced a send. Retry only unfinished work.
If the send outcome is unknown, check the destination before making another attempt. A connector timeout does not prove the receiving service did nothing.
Integration Error Handling Best Practices
- Key principle
- Retry only unfinished work
- Outcome uncertainty
- Do not auto-retry if send status is unknown
- Idempotency support
- Check destination docs — not all services support it
Separate the actions
Consider a workflow that sends an email and then updates a CRM record. If the update fails, replaying the whole workflow could send the email again. Record the outcomes separately: send confirmed at the provider, CRM update failed. Recover the update only.
An error on the send action is harder. A receiving service may have accepted a request without returning a timely response. Treat such a send as outcome unknown until destination evidence resolves it. Provider acceptance also differs from delivery to a recipient.
Identify one intended send
Give each intended send an opaque, stable key. Keep its campaign, message version, contact reference and send occasion in a controlled register. Reuse the same key for a retry of that intended send; use a new key for a genuinely authorised second send. Avoid putting an email address or other personal data into an API idempotency key.
If the receiving API supports idempotency keys, pass the same key on retries and follow its documented retention and parameter rules. Stripe documents one such API mechanism, but that does not establish that an email service supports it. Check the actual destination's documentation and available send history.
A register by itself cannot prevent duplicates when two workers read the same pending state. Where the system permits it, claim the send key atomically and prevent competing recovery workers. Without dependable destination-side idempotency or a reliable way to confirm the first send, hold an uncertain result for review rather than automatically sending again.
Choose a bounded recovery path
- Identify the failed action and earlier confirmed actions.
- Check the destination for the attempted action and any retry already scheduled.
- Correct permanent causes, such as missing data or an expired connection.
- Retry a confirmed unfinished action only within an agreed attempt and time limit.
- Record the result against the same intended action; hold any remaining uncertainty for review.
Before retrying, check the failed action's status and the destination's send history. If the destination supports idempotency, reuse the same key; if the outcome remains uncertain, do not automatically send again.
