What happened?

According to § 4.3.3. Push Notification Payload, the payload of a push notification is encapsulated in the kind of payload:

POST {webhook_url}
Authorization: {authentication_scheme} {credentials}
Content-Type: application/json

{
/* StreamResponse object - one of: /
"task": { / Task object / },
"message": { / Message object / },
"statusUpdate": { / TaskStatusUpdateEvent object / },
"artifactUpdate": { / TaskArtifactUpdateEvent object */ }
}

but at the moment, the payload is directly the content of a task:

{
  "id": "task_send_with_token",
  "contextId": "ctx456",
  "status": {
    "state": "completed",
    "timestamp": "2025-11-27T11:52:51.319262Z"
  },
  "artifacts": [],
  "history": [],
  "kind": "task"
}

instead, the payload should be encapsulated with the kind of payload. In the example above, it should be:

{
  "task": {
    "id": "task_send_with_token",
    "contextId": "ctx456",
    "status": {
      "state": "completed",
      "timestamp": "2025-11-27T11:52:51.319262Z"
    },
    "artifacts": [],
    "history": []
  }
}

I found out this issue while working on #490 which expands the kind of payload that can be pushed by notifications.

More generally, the kind discriminator is being been removed in 1.0(§ A.2.1 Breaking Change: Kind Discriminator Removed)

Additionally, the names of the kind were not compliant with the previous spec conventions. It uses status-update & artifact-update while the spec said the field names are taskUpdate & artifactUpdate.

The whole code needs to be updated to use properly wrapped object to returns task, message, text, etc. instead of the kind field.

References

• § 4.3.3. Push Notification Payload
• § 5.5. JSON Field Naming Convention
• § 6.1. Basic Task Execution
• § 6.2. Streaming Task Execution
• § A.2.1 Breaking Change: Kind Discriminator Removed

Code of Conduct

• I agree to follow this project's Code of Conduct