How A2A push notifications work

A2A push notifications are how an agent delivers results of long-running tasks without the client holding a connection. The client registers a webhook URL in a push notification config; the agent then sends HTTP POSTs to that URL as the task changes state. It's the A2A protocol's async mode, and it's webhooks by another name.

Receiving webhooks?

Svix Ingest is a reliable webhook receiver. It verifies signatures, absorbs delivery spikes, and gives you one endpoint for webhooks from any provider. Start receiving webhooks with Svix Ingest.

Registering the config

When a client sends a task it can attach a push notification config, or create one later against the task ID. The config is small: a required url to deliver to, an optional token the client generates so it can recognize its own registrations, and an authentication field describing the credentials the agent should present when calling the webhook. The agent assigns the config an id, and the client can list, fetch, or delete configs per task.

Support is opt-in. An agent declares capabilities.pushNotifications in its agent card, and a client should check that flag before planning an async handoff, because the fallback is polling.

What arrives at the webhook

As the task progresses, the agent POSTs update payloads to the registered URL: status changes as the task moves from working to a terminal state, and artifact updates carrying the actual output. The receiving side has the usual webhook endpoint obligations: respond fast with a 2xx, do the real processing off the request path, and tolerate the same update arriving twice.

The task lifecycle helps here. Every update carries the task ID and state, so a receiver can treat updates idempotently by keying on task ID plus state transition rather than trusting each POST to arrive exactly once.

What the spec doesn't cover

This is the part that surprises teams shipping A2A servers. The 1.0 spec defines the config shape and the payload, and stops there. It doesn't specify signatures proving the POST came from the agent rather than anyone who learned the URL, retry behavior when the client's endpoint is down, deduplication semantics, or any delivery observability. There's no challenge handshake to verify URL ownership either, so a malicious client can point an agent at a victim URL, which is the classic SSRF shape.

The authentication field carries credentials the agent presents when delivering, which authenticates the sender to the receiver if you build both halves. But every A2A server implementer is left to design their own signing, retry schedule, and delivery log, and every receiver has to handle each server's ad hoc choices.

Building the delivery layer

If you're implementing an A2A server, push notification delivery is a webhook sender, full stop, and the requirements are the well-understood ones: sign payloads with HMAC, retry failed deliveries with exponential backoff, disable endpoints that fail for days, and keep logs your users can check when a result goes missing. How to build a webhook sender covers the ground, and [Svix]https://www.svix.com/?utm_source=resources&utm_medium=content) is that sender as a service: your agent calls one API when a task changes state, and signing, retries, and per-endpoint delivery logs come with it.

On the receiving side, [Svix Ingest]https://www.svix.com/ingest/?utm_source=resources&utm_medium=content) gives an agent client a durable public URL that verifies and buffers what A2A servers deliver, which also solves receiving push notifications into agents that run without a public address. For the broader picture of where push fits among the alternatives, see agent to agent communication.

Frequently asked questions

Are A2A push notifications just webhooks?

Yes. The client registers a URL, the agent POSTs task status and artifact updates to it, and the receiver processes them like any webhook. The spec adds a config object and lifecycle around it but the mechanism and the operational concerns are standard webhooks.

Does A2A require signing push notifications?

No. The 1.0 spec defines an authentication field for credentials the agent presents when delivering, but no signature scheme, no retry policy, and no URL verification handshake. Implementers are expected to supply that layer themselves.

How does the receiving agent avoid processing an update twice?

Key on the task ID and state transition in each payload. Since delivery can be retried, a receiver should treat updates idempotently: seeing the same task reach the same state twice should have no additional effect.