The Code Pattern That Keeps Our Integrations Stable in Production

When you connect real systems - ERPs, APIs, AI workflows - things don’t behave cleanly.

Requests retry.

Webhooks get sent twice.

Sometimes something succeeds, but you don’t get the response.

And then you see it:

• duplicate orders


• repeated emails


• workflows triggering twice

This is normal in production.

The pattern that keeps this under control is idempotency.

The rule

Every action should be safe to run more than once.

Same input → same result.

If the same request hits your system twice, nothing should break and nothing extra should happen.

Where things usually go wrong

1. Partial execution

Something starts, then crashes halfway.

A retry comes in and runs everything again.

If you’re not careful, you create duplicates.

So instead of “just create”, you always check:

• does this already exist?


• should I update instead?

2. Multi-step flows

Most integrations don’t stop at one system.

You might:

• create something in one system


• then send it to another

If it fails in the middle, the retry should continue from where it stopped - not start from zero.

3. Side effects

This is where it gets visible.

Things like:

• sending emails


• charging payments


• triggering automations

If these run twice, users notice immediately.

So you need to control when they run and make sure they don’t fire again on retries.

What changed for me

I stopped assuming things run once.

Now I assume:

everything can retry

everything can duplicate

things can fail halfway

So the question is always:

what happens if this runs again?

In systems that run all the time, this isn’t an edge case.

This is how the system behaves every day.

And once you build with that in mind, a lot of production issues just stop showing up.