Docs

Events

2 min readUpdated September 19, 2026

Events renders a table of the events an API can emit, such as webhook events, each with a name, a description, and an optional example payload. It’s a good fit for documenting webhooks or any other event-driven part of an API, separate from the request/response endpoints themselves.

Adding the block#

  1. In the block editor, open the block inserter and search for Events.
  2. Add it to the page, usually on a dedicated webhooks or events reference page.
  3. Give the table a title, e.g. Webhook Events.
  4. Click + Add event for each event you want to document.

Settings#

SettingWhat it does
Table titleHeading shown above the table, e.g. Webhook Events.

Per row:

SettingWhat it does
Event namee.g. customer.created.
DescriptionWhat triggers the event and what it means.
Example payload (optional)A sample payload sent for this event.

Example#

One row: Event name customer.created, Description Sent when a new customer is created.

Webhook Events
Event Description
customer.created 🔗 Occurs whenever a new customer is created.
Example payload
{
  "id": "evt_1",
  "type": "customer.created",
  "data": {
    "id": "cus_1",
    "email": "jane@example.com"
  }
}

The block#

In the editor, this is one event row filled in as above, no shortcode needed.

The shortcode#

The same block, added as a shortcode instead, for a widget, classic-editor content, or a page builder that only accepts shortcodes. Since events is a JSON array, it can never go in a quoted attribute (a JSON array always contains a ], and the shortcode parser stops at the first literal ] it finds, quoted or not). It goes between the opening and closing tags instead:

[nahnu_code_block block="events" title="Webhook Events"]
[{"name":"customer.created","description":"Sent when a new customer is created."}]
[/nahnu_code_block]

Putting the JSON between the tags, rather than in a quoted attribute, is what keeps the shortcode from cutting off partway through.

How it renders#

A table titled “Webhook Events” with one row: customer.created and the description text.

Tips#

  • Use a consistent naming pattern across events, like resource.action (customer.created, customer.updated, customer.deleted), so the table reads as a set rather than a loose list.
  • Include an example payload wherever the event’s data shape isn’t obvious from its name and description alone.
  • Group related events next to each other in the table, in the order a reader is likely to look them up.

This website uses cookies to enhance your browsing experience and ensure the site functions properly. By continuing to use this site, you acknowledge and accept our use of cookies.

Accept All Accept Required Only