A2A vs webhooks: push notifications with a task around them

A2A push notifications are for following one delegated task to its end: the client registers a webhook for that task, and the agent POSTs each status change or new artifact in a payload the A2A specification defines. Plain webhooks are for a service telling its subscribers that events happened, in whatever event format, signing scheme and retry policy that service chooses.

An A2A push notification is a webhook. What A2A adds is everything around it: how the webhook is registered, what the body looks like, which task it belongs to, and what each side must check. What it leaves out is anything a plain webhook provider would normally decide for itself, such as body signatures.

Status as of September 26, 2026. Push notifications are an optional capability in A2A 1.0, a Linux Foundation project (release v1.0.1, May 28, 2026). Webhooks in general have no single standard. The main shared conventions are the Standard Webhooks specification, an Apache 2.0 community project, and OpenAPI, which can describe webhooks an API sends through its top-level webhooks field (since 3.1) and its callbacks.

What plain webhooks are for

A subscriber gives a service a URL, usually through a dashboard or an API. When something happens, such as a payment succeeding or a file changing, the service sends an HTTP POST to that URL. The receiver answers with a 2xx status, and the service retries on failure.

Each provider decides the details. The Standard Webhooks specification proposes common ones:

• Headers: webhook-id (a unique event ID, stable across retries and usable as an idempotency key), webhook-timestamp (Unix seconds) and webhook-signature.
• Signatures: HMAC-SHA256 with a shared secret, or ed25519 key pairs, over the ID, timestamp and body.
• Replay protection: receivers reject timestamps outside a tolerance window.
• Retries: exponential backoff with jitter, over a schedule that can span days. Only a 2xx response counts as success.
• Payloads: “thin” payloads that say something changed, or “full” payloads with the new state. Event types name the schema of each payload.

The unit is an event stream for an account or resource. It is long-lived, and the provider defines what “an event” means.

What A2A push notifications are for

In A2A, the unit is a task. A client that expects a long-running job registers a push notification config, either inside SendMessage or later with CreateTaskPushNotificationConfig. The config holds a url, optional authentication with a scheme and credentials, and an optional token unique to the task or session. It lasts until the task completes or the client deletes it. Illustrative request, JSON-RPC binding:

{
  "jsonrpc": "2.0",
  "id": 11,
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "b1f5c7e2-4a0d-4d59-9a57-2f1c3e8d6a41",
      "role": "ROLE_USER",
      "parts": [{ "text": "Book quote Q-1182 for 40 pallets, pickup Monday." }]
    },
    "configuration": {
      "returnImmediately": true,
      "taskPushNotificationConfig": {
        "url": "https://buyer.example.com/a2a/notifications",
        "authentication": { "scheme": "Bearer", "credentials": "illustrative-single-purpose-secret" }
      }
    }
  }
}

When the task changes, the agent POSTs a StreamResponse, the same object streaming uses, with exactly one of task, message, statusUpdate or artifactUpdate. It sends Content-Type: application/a2a+json and an Authorization header built from the credentials the client supplied. Illustrative:

POST /a2a/notifications HTTP/1.1
Host: buyer.example.com
Authorization: Bearer illustrative-single-purpose-secret
Content-Type: application/a2a+json

{
  "statusUpdate": {
    "taskId": "task-7c2e",
    "contextId": "ctx-91ab",
    "status": { "state": "TASK_STATE_COMPLETED", "timestamp": "2026-09-26T15:04:05Z" }
  }
}

The specification assigns duties to both sides. The agent must attempt delivery at least once, may retry with exponential backoff, should time out after roughly 10 to 30 seconds, and may stop after repeated failures. It should validate webhook URLs against server-side request forgery by rejecting private ranges, localhost and link-local addresses. The client must validate the credentials on each notification, check that the task ID is one it created, answer with a 2xx, and should process notifications idempotently.

Side by side

	Plain webhooks	A2A push notifications
Purpose	Notify subscribers of events in an account or resource	Report progress and results of one delegated task
Layer	Convention on top of HTTP; each API defines its own	Part of the A2A protocol; optional capability
Who talks to whom	A service to its subscribers’ endpoints	A remote agent to the client that delegated the task
Transport	HTTPS POST	HTTPS POST with application/a2a+json
Discovery and registration	Provider dashboard or API; OpenAPI can describe the events	Declared by capabilities.pushNotifications; registered per task
Auth	Chosen by the provider; commonly an HMAC signature with a shared secret	Chosen by the receiver: an HTTP scheme and credentials the agent must send
State	Long-lived subscription; event IDs for deduplication	Config lives until the task ends or is deleted; payload carries task state
Governance and status	No single standard; Standard Webhooks is a community specification	A2A 1.0, Linux Foundation

When to use each

Use A2A push notifications when you delegated a task to another organization’s agent and the work may outlast a connection: an approval, a claim, a booking that waits on a third party. You do not have to learn a new event format per counterparty, and the payload tells you the task’s state directly.

Use plain webhooks when you run a service and want to tell customers about events in their accounts, or when you consume a service that already offers them. A2A does not replace these event feeds.

Use streaming or polling instead when the client stays connected and the task is short. SendStreamingMessage and SubscribeToTask stream the same events over Server-Sent Events, and GetTask reads current state at any time.

Using both

Most A2A deployments involve both. An A2A agent often waits on webhooks from its own providers, such as a carrier confirming a pickup, then turns them into task updates for its client. On the receiving side, an A2A notification endpoint needs the same engineering as any webhook receiver: acknowledge fast, queue the work, deduplicate, and reconcile with GetTask after an outage.

The authentication gap deserves a decision. The A2A payload section describes credentials in an Authorization header, which shows who sent the request but does not sign the body or carry a timestamp. If you need body integrity or replay protection, agree on it with the counterparty or define it in an A2A extension. Options include Standard Webhooks’ signatures or HTTP Message Signatures (RFC 9421). This is our reading of the specification, which states no such requirement.

Common misconceptions

“A2A push notifications are just webhooks.” They are webhooks with a defined registration, payload and scope. The receiver still has to do everything a careful webhook receiver does.

“Push notifications replace polling.” Delivery is at-least-once and may stop after repeated failures. GetTask remains the source of truth for a task’s state.

“A bearer credential proves the payload is intact.” It shows the sender held the secret. It does not sign the body, so tampering in transit is prevented only by TLS on that hop.

“Only the receiver has security work.” The agent that sends notifications fetches client-supplied URLs, which makes it a potential SSRF path into its own network. The A2A specification tells agents to validate those URLs.