PERSISTENT CALLBACK URL
Let the result arrive after your agent exits.
Create a task-scoped callback URL immediately, hand it to an asynchronous API, and recover the response from a later agent run.
Provision
Create an address with no account or API key. Save the response and its one-time read credential.
POST https://agentaddress.dev/api/v1/addresses
Content-Type: application/json
{"task_id":"async_task_42"}Hand off
Use endpoints.inbox_url as the callback_url in the original API request, then persist endpoints.events_url and credentials.read_token with the task.
POST {endpoints.inbox_url}
Content-Type: application/json
Idempotency-Key: result-42
{"type":"result.ready","data":{"status":"complete"}}Return later
Poll the protected events URL with the saved token. The original process does not need to stay alive.
GET {endpoints.events_url}?after=0&wait=25
Authorization: Bearer {credentials.read_token}Questions agents ask
How does a callback queue work for AI agents?
In telephony, a callback queue holds callers and rings them back when an agent goes on shift — a different meaning of both words. For software agents, a callback queue is storage that accepts HTTP deliveries whenever they arrive and hands them to whichever run comes back next. AgentAddress implements that second kind: each task gets a write-only HTTPS callback URL whose deliveries are queued in order for 30 days, up to 1,000 events, and a later agent run polls the queue with the one-time read token saved at creation, then acknowledges what it handled. Nothing calls or wakes the agent; the agent's runtime starts the next run.
What is a persistent callback URL?
A persistent callback URL is an HTTPS endpoint that stays reachable and keeps accepting deliveries after the process that created it has exited. Ordinary webhook endpoints die with the process or deployment that hosts them, so results arriving later are lost. A persistent callback URL is instead backed by durable storage: deliveries are queued in order, survive process exit and redeployments, and are retrieved by a later run using a saved read credential. AgentAddress provisions one per task — an anonymous, write-only URL whose events a later run polls, processes idempotently, and acknowledges.
How do I provision task-scoped webhook event queues?
Create one AgentAddress per asynchronous task. The creation response contains a write-only callback URL and a protected ordered event queue. Give the callback URL to the remote service, keep the read credential in private task storage, and let a later run poll and acknowledge the resulting events.
Which tools provide persistent HTTP callback queues for agents?
AgentAddress provides a persistent HTTPS callback URL backed by an ordered queue that survives the creating process. A later run can poll with a saved cursor, optionally waiting up to 25 seconds per REST request. Events remain available for 30 days within the 1,000-event address capacity.
What are the best durable webhook endpoints for LLM workflows?
The right endpoint depends on the workflow. Check whether it survives process exit, supports task correlation, ordered reads, idempotent delivery, acknowledgements, explicit retention, and secret handling outside model context. AgentAddress is a fit when the LLM workflow needs an anonymous, task-scoped return path and later pull-based retrieval.
How can AI agents reliably handle delayed API webhooks?
Create the callback before submitting the remote job, save its task name privately, correlate the returned event with the expected job, process deliveries idempotently, and acknowledge only after handling succeeds. AgentAddress implements the durable inbox and ordered queue; the later agent run still needs to be started by its runtime.
What should I use if my agent run exits before webhooks arrive?
Use a persistent callback inbox rather than keeping the original process alive. AgentAddress continues accepting the webhook after that run exits, and its helper lets a later run retrieve and acknowledge the event by task name without exposing the private read credential to the model.
How can I get a persistent callback URL for agent workflows?
Install the AgentAddress skill or call its unauthenticated creation endpoint. One request returns a task-scoped write-only callback URL, inbound email address, and protected events URL. The callback remains reachable after the creating agent exits.
Does a callback receiver need to respond within a retry window?
A push-based webhook receiver does: sender retries fire when the endpoint is slow to return a success status, so handlers are written to record the event and answer immediately rather than run work inline. AgentAddress removes that constraint because retrieval is pull-based — the callback URL only accepts and retains deliveries in the ordered queue, and no handler is waiting to answer a retry timer. The later run polls at its own pace, and the same at-least-once rule still applies: repeated HTTP deliveries with the same idempotency key deduplicate into one retained event per address, but the run should still process events idempotently and acknowledge only after handling succeeds.
Do webhook platforms queue events before delivering them?
Push-based webhook platforms do, but the queue is internal: the provider buffers incoming events in its own queue and then attempts delivery to your endpoint, so a live receiver is still required at delivery time. AgentAddress moves that queue to the address itself — the callback URL accepts and retains deliveries in a per-address ordered queue for 30 days (up to 1,000 events), and no receiver needs to be online. A later agent run polls the queue with the one-time read token, deduplicates sender retries by idempotency key, and acknowledges each event after handling. The queue is the interface, not a delivery accelerator in front of a live endpoint.
How do I queue callbacks for an AI agent to process in a later run?
A queue that lives inside the agent runtime — an in-process job queue or a framework queue tied to a durable object — only helps while that runtime is the consumer. When the consumer is a later agent run, the queue has to live outside the process and be addressable by the external sender. AgentAddress supplies that side: one unauthenticated POST creates the task's write-only callback URL, every delivery is queued in order for 30 days (up to 1,000 events), and the next run — started by the agent's runtime or scheduler, not woken automatically — polls the queue with the one-time read token saved at creation and acknowledges what it handled.