Asynchronous Architectures: Handling Webhook Callbacks from AI Agents and LLMs The early days of LLM apps were simple: send a prompt, wait a couple of seconds, get text back.

Asynchronous Architectures: Handling Webhook Callbacks from AI Agents and LLMs

The early days of LLM apps were simple: send a prompt, wait a couple of seconds, get text back. That model doesn't hold anymore. Modern AI workloads — long video generation, fine-tuning jobs, multi-agent pipelines that browse the web, call tools, and cross-check their own output — routinely run for minutes or hours, not milliseconds.

That single fact breaks the request-response assumption baked into most web infrastructure. If your server holds a connection open while an agent "thinks," you'll hit gateway timeouts, exhaust your thread or connection pool, and lose expensive work the moment traffic spikes. The fix the industry has converged on is the same one used for payments, shipping, and CI/CD long before LLMs existed: acknowledge the request immediately, do the work in the background, and deliver the result later via a webhook callback.

This post covers why that shift is now unavoidable for AI workloads, what the major model providers actually support today (this changed significantly in 2025–2026), how to architect the receiving side, and the operational pitfalls — idempotency, signature verification, malformed payloads — that trip people up in production.

Why Long-Running AI Workflows Break Traditional APIs

A typical modern AI pipeline might: ingest a large document, run OCR and vision extraction, hand the content to a multi-agent reasoning step that fact-checks against external sources, and then generate a summary or slide deck. Each of those stages can take real time, and the whole pipeline can easily run into minutes.

Standard web infrastructure was never built to hold connections open that long. A few concrete, verifiable limits:

Amazon API Gateway defaults to a 29-second integration timeout for REST APIs (30 seconds for HTTP APIs). AWS allows raising this above 29 seconds for Regional and private REST APIs via a service quota increase, but edge-optimized APIs are capped at 29 seconds regardless.
API Gateway also enforces a hard 10 MB limit on both request and response payload size — not configurable — which matters once you're returning large JSON structures full of embeddings or reasoning traces. AWS Lambda's own synchronous response limit is smaller still, at 6 MB.
Most reverse proxies, load balancers, and browser clients apply their own timeouts well under a minute unless explicitly tuned.

Hold an HTTP thread open while a multi-agent job runs, and a burst of concurrent requests will exhaust your connection pool fast. This isn't a hypothetical scaling problem — it's the default behavior of the infrastructure most teams already run.

Polling vs. Webhooks

The naive first fix is polling: submit a job, get a job_id, and hit a status endpoint every few seconds until it flips to completed. It works, but it wastes compute on both sides, adds unnecessary database reads, and introduces a delay between "the job actually finished" and "your system noticed." Webhook callbacks invert this: your system submits the job and goes quiet. When the provider finishes, it makes a new outbound HTTP request to a URL you control, delivering the result exactly when it's ready. For workloads with unpredictable completion times, this is strictly more efficient — you trade a constant polling loop for a single push notification.

What AI Providers Actually Support Today

This is the part that's changed the most, and it's worth being precise, because the two major model providers implement webhooks differently.

OpenAI shipped native webhook support in 2025, but only for specific asynchronous endpoint families:

✅ Batch API — fires batch.completed (and related lifecycle) events when a batch job reaches a terminal state.
✅ Background Responses / Deep Research — fires response.completed when an async response or research job finishes.
❌ Chat Completions and Assistants runs — these are still synchronous or stream-based only; there is no webhook for them. You poll or stream.

Critically, OpenAI webhooks are configured at the project level in the dashboard, not passed as a field on each individual API call — you register a destination URL and signing secret once, and every eligible event for that project routes there. The OpenAI SDK ships a helper (openai.webhooks.unwrap() in Node, an equivalent in Python) that verifies the signature and parses the event for you rather than requiring you to hand-roll HMAC comparison.

Anthropic's Claude API takes a different shape: webhooks apply to the Batch API specifically, and the destination is set per-request via a webhook_url field when you create the batch. Anthropic signs the callback with HMAC-SHA256 over the timestamp and raw body using a shared secret. As with OpenAI, there's no webhook for a single synchronous messages.create call — only for batch jobs, which can take anywhere from minutes up to 24 hours.

The practical takeaway: if your architecture assumes every AI call can be webhook-driven, check the specific endpoint. Webhooks today cover batch and explicitly-async endpoints; anything synchronous still needs streaming or polling.

The Webhook Callback Pattern, End to End

Whether the trigger is an OpenAI batch, a Claude batch job, or your own multi-agent pipeline built on LangChain, CrewAI, or n8n, the receiving architecture looks the same:

1. Acknowledge immediately. The endpoint that receives the initial request (a file upload, a scheduled trigger) should do the minimum possible work — validate input, write a pending row to a database — and return 200/202 right away. Don't do AI work on this thread.

2. Hand off to a background queue. Push the job onto a message broker (Redis, Amazon SQS, Kafka) or a durable execution platform. A separate pool of workers, not bound by public-facing gateway timeouts, picks it up.

3. Execute with checkpointing. This is where a distinct category of tooling has matured specifically because of AI workloads: durable execution engines. Temporal, Inngest, Trigger.dev, and Restate all journal every step of a workflow so that if a worker crashes 29 minutes into a 30-minute job, it resumes from the last completed step instead of restarting and re-burning tokens. This matters more for AI pipelines than typical background jobs, because each step usually costs real money in API calls — Inngest's own engineering writing makes the point that a five-step agent pipeline at 99% reliability per step only succeeds end-to-end about 95% of the time, and that gap widens fast as agents get more compositional. Which engine fits depends on your stack: Inngest is generally the fastest to bolt onto an existing serverless app, Trigger.dev leans into long-running TypeScript-native workers with a strong self-hosting story, and Temporal or Restate suit teams that want the orchestration guarantees baked deeper into service boundaries.

4. Deliver the result via webhook. Once the worker finishes, it POSTs the final payload to your destination URL — the callback the rest of this post is about.

Receiving the Callback Without Losing Data

The failure mode nobody plans for: your database is mid-restart, or a deploy is in progress, at the exact moment the provider's webhook fires. If your receiving endpoint isn't up, you can lose hours of paid compute, and most providers only retry for a limited window before giving up.

This is the argument for putting a durable intake layer in front of your application endpoint rather than pointing providers directly at it. The pattern — accept the payload immediately, encrypt and store it outside the request path, retry delivery to your actual backend with backoff, and keep a dead-letter queue for anything that keeps failing — is common enough that it's become its own small tooling category: Svix, Hookdeck, Hooklistener, and InstaWebhook are current examples, each offering delivery timelines, signature handling, and replay so a failed or malformed event isn't just gone. Some (InstaWebhook among them) also offer a "bring your own database" mode, letting sensitive payloads land directly in infrastructure you control rather than a vendor's — relevant if the AI pipeline is touching PHI or PII and you need to keep SOC 2 or HIPAA boundaries intact. Whether you buy this layer or build a thin version of it yourself with a queue and a retry policy, the underlying requirement is the same: the moment of receiving a webhook and the moment of acting on it should not be the same code path.

Best Practices for Consuming AI Webhooks

Enforce idempotency. Providers retry webhooks — because of network blips, because your endpoint was briefly down, because a proxy in front of you double-delivered. Your handler must tolerate receiving the same event twice without double-processing it (double-charging a customer, sending two identical emails). Key off the provider's unique event or job ID, check whether you've already recorded it as processed, and if so, return 200 and exit without repeating the side effect.

Verify the signature before you trust the body. A webhook endpoint is a public HTTP endpoint, which means anyone can POST to it. Both OpenAI and Anthropic sign their webhook deliveries — validate the signature (and the timestamp, to reject stale replays) using your provider's SDK helper or a constant-time HMAC comparison before you parse or act on the payload.

Keep ingestion and business logic separate. The function that receives the HTTP request should verify the signature, persist the raw payload or push it to an internal queue, and return 200 — nothing more. A separate worker, not exposed to the public internet, should be the one that parses the payload, applies business logic, and triggers downstream effects like a UI update or notification. This keeps a slow or buggy business-logic step from ever causing you to miss or drop an incoming webhook.

Plan for malformed AI output. Unlike a payment processor's rigidly-typed webhook, an AI pipeline's output can be genuinely unpredictable — a model can omit a field your parser expects, or return a string where you expected a number. Without a dead-letter queue, one malformed payload can jam a retry loop indefinitely. Shunt anything that repeatedly fails validation into a DLQ you can inspect, fix your parsing logic against the real payload, and replay.

Conclusion

Synchronous request-response was never designed for workloads that take minutes to hours, and forcing it to work anyway just produces timeouts and lost compute. The fix is architectural, not clever code: acknowledge fast, hand real work to a background queue with a durable execution layer underneath it, and receive results through webhooks built to survive retries, bad signatures, and your own downtime. The good news for 2026 is that this is no longer something every team has to build from scratch — both OpenAI and Anthropic now ship native webhook support for their async endpoints, and a mature layer of durable-execution and webhook-intake tooling has grown up specifically to handle the parts that are easy to get wrong.

Sources

Note: this piece was checked against publicly available documentation as of July 2026; provider webhook support is evolving quickly, so verify current event names and configuration steps against OpenAI's and Anthropic's own docs before shipping.