Activepieces published a guide to webhook retry logic, and its best line is a diagnosis rather than a tip: “attempting to resend a failed webhook notification the instant a network error occurs transforms a transient glitch into a self-inflicted Denial of Service attack.” The fix is three mechanisms that have to arrive together — a queue-first architecture, exponential backoff with jitter, and idempotency keys — and the reason they are inseparable is that each one creates the problem the next one solves. Accepting fast enough to meet a timeout means you have not processed yet. Retrying safely means you will deliver twice. Their analogy for the first part is better than most architecture diagrams: separate “the receptionist who answers the door from the accountant who processes the paperwork, preventing a backlog in the office from blocking the entrance.”
What makes the piece genuinely useful is that it publishes the numbers nobody wants to look up. Receiver timeout windows: Slack 3 seconds, Shopify 5, GitHub 10, Twilio 15, Stripe 30. Retry budgets: GitHub 50 attempts, Stripe 17, Shopify 8, Slack 3. A consumer writing one handler against four of those is writing against four different contracts, and the spread is the argument for queue-first on its own — there is no processing you can reliably finish inside three seconds. The reliability figures quoted alongside them, a 15% initial failure rate and 92% recovery under exponential backoff against 85% under fixed intervals, are unattributed and should be read as illustrative. The timeout table needs no such caveat; it is checkable, and it is the part worth bookmarking.
The catalog reads nine API pages for Activepieces, and the post is a description of what happens inside them. The Flow Runs API is every retry attempt as a record, the Flows API is where Auto Retry on Failure and Continue on Failure are configured, the Connections API holds the credentials each replay re-authenticates with, and the Pieces API is the integration surface inheriting all five of those timeout budgets at once.
Activepieces scores 42.2, developing on the Kin Score, with discoverability at 68.5 and developer ergonomics at 53.6 against access clarity at 26.3 and contract quality at 34.3. Agent Readiness is 29.7, agent-ready — mcp_server, auth_clarity, openapi_examples and rate_limit_signal lit. The two dark ones are the two this post exists to explain. idempotency is unlit, on the company whose central recommendation is that “idempotency keys ensure that processing the same webhook payload multiple times results in exactly one state change.” event_surface_described is unlit, on a webhook platform. Every receiver timeout in that table is a number some provider chose to publish. Activepieces just wrote the clearest available case for publishing them, about everyone except itself.