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 (fires from any surface, editor or topic list) |
| A topic is permanently deleted |
| 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.
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. Topics created in the app include a title and status; topics created through the REST API include 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
The component.created payload includes a title, 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