Skip to content

Automation & Orchestration

Webhook orchestration: acknowledge fast, process later, never twice

Your payments provider, scheduling tool and CRM can all call you when something happens. They do it on their terms: they retry when you're slow, send the same event twice, deliver out of order, and anyone can pretend to be them. Webhook orchestration verifies every call, stores it, answers at once, and does the real work from the stored copy. For you, that means a payment or booking from another system is recorded once, even on that system's bad day.
Discuss your systemSee the five checks ↓
verifystorereply 200queueprocessretryeventresultevt_901 · payment.succeededstored · 200 · INV-2263 marked paidunsigned requestrejected · 401 · not storedevt_901 · sent againalready seen · 200 · skippedevt_455 · job.updatedstored · 200 · retried · synced

A webhook is someone else's promise

When you connect a payments provider or a scheduling tool, it calls an address you give it whenever something changes. That's better than checking every few minutes, but you don't control the caller. If you're slow to answer, it retries. It may send the same event twice, or in a different order. And without a check, anyone who finds the address can send you a fake one.

Webhook orchestration makes the receiving end dependable. Each call is verified, stored before anything else, answered quickly, and then processed from the stored copy by a worker that knows which events it has already handled. Nothing is lost when a downstream system is down, and nothing happens twice.

Five checks every webhook passes

  1. 01

    Verify the sender

    Is it really them?

    The signature on every call is checked with the secret you share with the sender. Anything unsigned or altered is rejected.

  2. 02

    Store it first

    Before doing anything

    The event is saved as it arrived, so a crash a moment later loses nothing.

  3. 03

    Answer fast

    Then do the work

    The sender gets its 200 at once. Slow work happens afterwards, so the sender doesn't retry while you're busy.

  4. 04

    Recognise repeats

    Same ID, same outcome

    Each event's ID is remembered. A repeat is acknowledged and skipped, so a payment is never recorded twice.

  5. 05

    Process from the stored copy

    Retry without asking again

    If the work fails, it's retried from what was stored, in order where order matters, and a person is told if retries run out.

Three deliveries

The normal case takes a moment. The others are why the design matters.

evt_901 · payment.succeeded

  1. Signature verified

    done

  2. Stored

    done

  3. Answered 200

    done

  4. Invoice INV-2263 marked paid

    done

  5. Customer receipt sent

    done

The provider got its answer at once; the work followed from the stored copy.

What webhook orchestration hands off

In

Incoming calls
from your other systems
Shared secrets
one per sender
Event history
what's already handled
Webhook intake
verify → store → reply → process

Out

Stored events
exactly as they arrived
Triggered work
once per event
Alerts
when retries run out

Worth building when other systems tell you things

Good fit

  • Payments, scheduling, CRM or form tools can send you events.
  • Today those events trigger things directly, with no record.
  • A duplicate or missed event has caused a problem.

Not the right fit

  • The system you need data from can't send events. Scheduled reads are the answer there.
  • A handful of events a month that a person can check.

Where it's built in

Next to webhook orchestration

Questions about webhook orchestration

Why answer before the work is done?

Because the sender is waiting. If you take too long it assumes failure and sends again. Storing the event and answering at once keeps the sender happy and leaves the work to a worker that can take its time.

What if events arrive out of order?

Each event carries a time or a version. Where order matters, such as a job's status, the worker applies only what's newer than what it already has.

Where do the webhooks land?

An endpoint we build for you, often a small serverless function in front of a queue, or n8n's webhook node for simpler cases. These are starting candidates, not requirements.

What happens if we change the shared secret?

Both the old and new secrets are accepted for a short overlap, so no real event is rejected while the sender switches over.