Automation that survives its first error
The flow that works on a good day is easy. What matters is what happens at 3am when the API on the other side goes down.
Automation is written for the happy path and lives on the unhappy one. The API returns a 500, the webhook arrives twice, the spreadsheet changes a column, the customer types the phone number with an extra space.
Three things I never leave out
Idempotency: the same webhook can arrive twice, and the system must produce the same result. Without it, the customer gets charged twice and you find out from support.
Retry with growing backoff: network failures are usually temporary. Retrying immediately, three times in a row, is the fastest way to turn a wobble into a block.
A log of what ran: not the one the framework emits on its own, but a readable record of which trigger fired, with what input and what result. That is what turns "it didn't work" into an answer in five minutes.
A queue is almost always the answer
Once volume grows, processing straight inside the webhook stops working. Putting a queue in the middle costs little early and avoids a full rewrite later — and gives you, for free, the right place to replay what failed.
The test that counts
Take the dependency down on purpose and watch. If the flow loses data, it is not ready. If it stops, complains, and picks up where it left off when the dependency returns, it is.