A failure that is loud
A dead endpoint is retried for a little over 24 hours, and if the last attempt still fails your workspace admins are emailed — once per endpoint per day, not once per order.
Order sync
Validate the payload, upsert the customer, call the system that fulfils it, and retry for a day if it goes quiet — with one run and one trace behind every order.
The problem
A sync between two systems is easy to build and hard to trust. The failures are quiet: a field that changed shape, a token that expired on a Friday, an endpoint that answered 200 and did nothing. None of them page anyone, and all of them surface a week later as an order that was paid for and never shipped.
The usual fix is a dashboard that says how many runs succeeded. That answers the wrong question. What you need is the one order — this one, from March — and what was actually sent, what came back, and how many attempts it took.
What the flow looks like
Numbered because the order is the execution order, not because it is a list. However many steps it has, the whole thing is one run.
Your store, your checkout or your payment provider posts the order the moment it is paid.
Required fields, a shippable address, a line total that matches. A payload that fails stops here with a reason, rather than half-writing itself into two systems.
Keep the customer and the order as records with their own schema, so the next order from the same person does not start from nothing.
A packaged provider, or a Custom Connection to any HTTPS or JSON API you have credentials for — your warehouse, your ERP, your 3PL, your own internal service.
Where the record has to land in your warehouse rather than in a vendor, the flow writes it directly during the run.
A rejected order goes down its own branch: alert the channel that owns it, and keep the payload so it can be replayed rather than retyped.
Post the failures where an operations person will see them today, with the response code and the order reference.
Return the fulfilment reference so the calling system can store the same identifier the flow received.
What the flow can reach
A Connection node calls one of 52 packaged providers, or any HTTPS or JSON API you have credentials for. Six databases connect directly. Every call happens inside the run, with your credentials, and lands on the same trace as the rest of it.
What changes
A dead endpoint is retried for a little over 24 hours, and if the last attempt still fails your workspace admins are emailed — once per endpoint per day, not once per order.
Open the run for that order and read what was sent, what came back, and how many attempts it took. Not an aggregate; the order itself.
The new version runs against payloads you kept, and live traffic keeps running the published one until you publish. A half-finished change cannot leak into production.
Questions
Yes. A Custom Connection speaks any HTTPS or JSON API you have credentials for — you give it the endpoint, the auth and the request body template. Fifty-two providers are packaged for convenience; the Custom Connection is what covers everything else.
The delivery is retried six times on a widening gap: immediately, then after 5 seconds, 30 seconds, 5 minutes, 1 hour and 23 hours — a little over a day in total. Retries are free, so an order that took six attempts is still one run.
Live traffic only ever runs a published version. Edit the draft, run it in Sandbox against payloads you kept, then publish — or move a percentage of orders onto the new version first and compare the runs before it carries everything.
Ready when you are
Build the flow in Sandbox, run your own cases through it, and read the trace before anything reaches a customer.