Webhook event reference
This reference lists every event type available when Configure webhooks. Each event includes its trigger condition and an example payload.
Event list
Event | Trigger |
|---|---|
| A new topic is created |
| A topic's content or metadata (title, tags) changes |
| A topic's status becomes Published from the editor, from a topic's status badge in the topic list, from a bulk status change, or over the REST API |
| A topic is permanently deleted, singly or in a bulk delete |
| A topic's status changes (Draft, Review, Published) |
| A new component is created |
| A component's content changes |
| A component is permanently deleted |
| A publication target is published |
| A publication target is unpublished |
Subscribe to * to receive every event.
Bulk actions in the topic list fire one event per topic. Changing the status of several topics together sends a topic.status_changed for each topic that moved, plus a topic.published for each when the new status is Published, and never a topic.updated. Deleting several topics together sends one topic.deleted per topic removed. A topic with an active workflow is excluded from a bulk status change and fires nothing.
Common payload fields
Every webhook payload has these three top-level fields:
Field | Type | Description |
|---|---|---|
| string | The event type (for example, |
| object | Event-specific data (see below) |
| string | ISO 8601 timestamp of when the event occurred |
The delivery is signed with HMAC-SHA256 in the X-Topicary-Signature: sha256=<hex> header. See Configure webhooks for how to verify it.
Example payloads
topic.created
The data fields depend on where the topic was created. A topic created from the editor or the topic list includes a title and status; one created through the REST API or an XLIFF import carries only the ID.
{
"event": "topic.created",
"data": {
"id": "topic_xyz789",
"title": "Untitled Topic",
"status": "draft"
},
"timestamp": "2026-06-09T14:30:00Z"
}topic.updated
The data includes the topic ID and the list of fields that changed.
{
"event": "topic.updated",
"data": {
"id": "topic_xyz789",
"fields": ["title", "content_json"]
},
"timestamp": "2026-06-09T14:30:00Z"
}topic.deleted
{
"event": "topic.deleted",
"data": {
"id": "topic_xyz789"
},
"timestamp": "2026-06-09T14:30:00Z"
}topic.status_changed
{
"event": "topic.status_changed",
"data": {
"id": "topic_xyz789",
"status": "published"
},
"timestamp": "2026-06-09T14:30:00Z"
}topic.published
Fired when a topic's status becomes published, in addition to topic.status_changed. Use this when you only care about the publish moment (for example, a Zapier "Topic Published" trigger) and do not want to filter topic.status_changed payloads by status.
{
"event": "topic.published",
"data": {
"id": "topic_xyz789"
},
"timestamp": "2026-06-09T14:30:00Z"
}component.created / component.updated / component.deleted
A component.created payload from the app includes a title; one from the REST API carries only the ID, the same split as topic.created. component.updated includes the changed fields, and component.deleted includes only the ID.
{
"event": "component.updated",
"data": {
"id": "comp_def456",
"fields": ["content_json"]
},
"timestamp": "2026-06-09T14:30:00Z"
}map.published / map.unpublished
{
"event": "map.published",
"data": {
"target_id": "target_jkl345",
"map_id": "map_ghi012"
},
"timestamp": "2026-06-09T14:30:00Z"
}Use the event field to route payloads to the appropriate handler in your integration. Subscribe only to the events you need. Fewer subscriptions mean fewer deliveries to process.
See also
Configure webhooks: create webhooks and verify HMAC signatures
REST API overview: programmatic access for reading and writing data
Security and data handling: HMAC-SHA256 webhook signature verification