A2A push notifications

The Agent2Agent (A2A) protocol lets agents delegate tasks to each other. For long-running or disconnected tasks, A2A defines push notifications: the serving agent POSTs StreamResponse payloads to a webhook URL the client registered through PushNotificationConfig.

That is a webhook. It needs exactly what Mittr already provides: authenticated receipt, retried and dead-lettered delivery, and a verifiable audit trail. Mittr is the reliability layer A2A assumes but does not implement.

When your agent is the client that registered the webhook, point it at a Mittr inbound endpoint and pick the preset that matches how the sending agent authenticates:

Mittr checks the credential in constant time, refuses the request with 401 when it does not match, and records every receipt (verified or rejected, with the reason) in the request inspector. An endpoint with no credential saved refuses traffic rather than accepting it unverified.

Both presets read the event type from $.body.kind, the discriminator a StreamResponse carries, so one endpoint can route statusUpdate and artifactUpdate to different destinations. See Inbound Webhooks for routing and the request log.

For mTLS senders, terminate the client certificate at your proxy and forward verified requests to the endpoint.

When your agent is the server that must notify a client about task progress, dispatch through Mittr instead of POSTing directly. Mittr retries with backoff if the client is unreachable, dead-letters what cannot be delivered, and records every attempt, so a task update is never silently lost.

The client gave you a PushNotificationConfig. Map it onto an endpoint: its url becomes the destination, and its token (or whatever its authentication says) becomes a custom header, which Mittr sends on every delivery.

curl -X POST https://app.mittr.io/api/v1/endpoints \
  -H "X-API-Key: mtr_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://client-agent.example.com/a2a/push",
    "eventTypes": ["statusUpdate", "artifactUpdate"],
    "customHeaders": { "Authorization": "Bearer <the client_token>" }
  }'

Then send task updates as they happen. The body is the StreamResponse itself, so the client receives exactly what A2A specifies:

curl -X POST https://app.mittr.io/api/v1/events \
  -H "X-API-Key: mtr_your_key" \
  -H "X-Idempotency-Key: task_abc123-completed" \
  -H "Content-Type: application/json" \
  -d '{
    "eventType": "statusUpdate",
    "payload": {
      "kind": "statusUpdate",
      "taskId": "task_abc123",
      "status": { "state": "completed" }
    }
  }'

An agent can do the same through mittr_send_event over MCP. Because the idempotency key is derived from the task and its state, a retried notification is delivered once, not twice.

Mittr also signs each delivery (X-Mittr-Signature), which is additive: the client’s own credential still rides in the header you configured, so a receiver that only understands A2A is unaffected.

• Reliability the protocol leaves to you. A2A specifies the message shape and auth; it does not guarantee the notification arrives. Mittr does: persist, retry, dead-letter, replay.
• One audit trail across agents. Every inter-agent task update, sent or received, lands in the same audit trail as your webhooks and MCP actions. You can prove what one agent told another and when.
• Idempotent by default. Retried notifications carry an idempotency key, so a redelivery never double-applies a task update.
• Correlated by task. A task update’s taskId is recorded as the action’s agent run id, so everything belonging to one task groups together in the action ledger alongside actions agents dispatched over MCP. Ask “what happened for task_abc123” and the whole sequence comes back, whichever protocol carried each part.
• Same engine, no new infrastructure. A2A push, MCP tool actions, and classic webhooks all run through the one delivery engine. See What Mittr is.

• Mittr does not model A2A tasks. It delivers and records notifications; it does not track task state, hold a task registry, or serve an Agent Card. Mittr is infrastructure under your agents, not an agent.
• Rotating credentials. A2A’s token is unique per task or session. A session-scoped token is stable for the endpoint’s lifetime, so the bearer preset handles it: paste it once. A token that rotates per task cannot be matched by a fixed string, and the answer there is the JWT preset, which trusts the issuer rather than a literal value. Mittr does not maintain a rotating token registry, because the client mints those tokens and Mittr would always be a step behind.
• mTLS is terminated at your proxy, not by Mittr; forward already-verified requests to the endpoint.

MCP is how an agent calls Mittr as a tool to dispatch actions. A2A is how agents notify each other about tasks. Mittr sits under both: it is the reliable, audited delivery layer for MCP tool actions and A2A push notifications alike.