chore(kno-11767): update outbound webhook event_data documentation

[rachael-t]

Description

These changes update the outbound webhook docs to address recent customer confusion about the use of the EventData type for event_data. This also makes changes to the <Attributes> component to allow for optional, nested content in a collapsible section.

• First, in /outbound-webhooks/overview:
  • I updated the sample event payload to use message.undelivered (since we previously used message.sent which wasn't an event type that actually included event_data so it was potentially misleading).
  • I then added a more detailed/realistic example of what that event_data would look like.
  • Additionally, I added a sentence explaining more about event_data and that it is null for most event types.
• Second, in /outbound-webhooks/event-types:
  • I added a callout at the top to again add some clarification about event_data, and its presence being event type specific.
  • I then changed type="EventData" to type="object" since there is no shared EventData schema.
  • I also updated the description for the retryable field description on message.delivery_attempted to clarify that it might be absent
  • I did some changes to the nest event_data attributes in an expandable field, which is detailed below.
• Third, I updated our <Attributes> component so that a single <Attribute> could show optional nested content in a collapsible section, similar to what we do in the API reference docs with "Show possible types"

Tasks

KNO-11767

Screenshots

Before:

After:

[linear]

KNO-11767 [Docs] Improve outbound webhook event_data documentation clarity

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Mar 3, 2026 10:28pm

[cellomatt]

I love the nested attributes update here, I think that makes a lot of sense and it definitely makes the page clearer.

A couple notes:

• It's true that we don't document a shared EventData schema that we can link to (because in the API it's the data on a MessageEvent), and the parameters that are included in the EventData will differ based on the type of the event. However, EventData is a type that we return on the webhook (i.e. "__typename": "EventData"), so I think that's the semantically-correct way to document it. If you feel strongly otherwise I think we should get a second opinion just to make sure 👍
• As far as I'm aware, there could also be some variations between providers and whether or not this additional data is available, so I think we should adjust the language on the callout to make it clearer that:
  • EventData is not present on every event type, and will be null when it isn't available
  • The availability or content of the data can vary by provider

[rachael-t]

@cellomatt thanks for reviewing 🙌

1. Regarding the EventData - yeah it just felt slightly confusing that some of the types had a shared schema and linked to the details in the API reference, but this one didn't since it didn't have one shared schema (that and because it's not in the API reference). I think initially I felt adjusting this to be type="object" made more sense, but now with the collapsible nested attributes, I think that leaving it as type="EventSchema" is okay and more clear than it originally was (this was customer feedback we received that initiated this PR). I'll update it. 👍

2. Yup good call - will action as well 👍

[cellomatt]

:chefs-kiss:

Great update, thank you!!