I think you're right. The answer that works nicely is: place the event in a queue and process the queue with retries idempotently. For robustness, you probab

I think you're right. The answer that works nicely is: place the event in a queue and process the queue with retries idempotently. For robustness, you probably also want good logging and, if possible, an event store for things like replay. Shameless plug: One of the use cases of our product at https://www.inngest.com https://www.inngest.com is reliably handling webhooks. We accept a JSON payload, can optionally transform it using ES6 on ingestion, then do a few things: - Fully type (and typecheck) the payload - Store the payload in an event store - Run N functions triggered by the payload, backed by a full idempotent queue (eg. your function can forward the event to your own API, and retry on failure) This lets you do a lot: you get reliability because we'll continue to retry your API endpoint if it fails. You also get local testing, replay, and historical retries for free because we store the payload. For example, you can `inngest run --replay` from the CLI to replay historic events from your webhooks. It's complex to build, but good event-driven architectures help with this. Disclaimer: I built inngest :)