Developer quickstart
Minimal handler (tickets only)
Checklist
- Use
eventId
for idempotency; store processed IDs for 24–48h. - Fetch full ticket via API if you detect truncated fields.
- Treat
ticket:updated
as a meta-event and listen for the derived specific events. - Process asynchronously; do not block the HTTP response.
Event types
Core lifecycle events
ticket:created
Triggered when a new ticket is created.
Payload structure:
ticket:updated
Triggered when a ticket is updated. This is a general update event that may trigger additional specific events.
Payload structure:
Same as ticket:created
, but includes:
ticket:deleted
Triggered when a ticket is deleted.
Payload structure:
ticket:archived
Triggered when a ticket is archived.
ticket:unarchived
Triggered when a ticket is unarchived.
State change events
These events are automatically triggered when specific fields change during aticket:updated
event:
ticket:status:changed
Triggered when the ticket status changes.
ticket:priority:changed
Triggered when the ticket priority changes.
ticket:assigned
Triggered when the ticket is assigned to a different agent.
ticket:type:changed
Triggered when the ticket type changes.
ticket:sentiment:changed
Triggered when the ticket sentiment changes.
ticket:escalated
Triggered when a ticket is escalated.
Custom field events
ticket:custom_field_value:added
Triggered when a custom field value is added to a ticket.
Additional payload:
ticket:custom_field_value:removed
Triggered when a custom field value is removed from a ticket.
Additional payload:
ticket:custom_field_value:changed
Triggered when a custom field value is changed on a ticket.
Additional payload:
Tag events
ticket:tag:updated
Triggered when tags are added to or removed from a ticket.
Migration events
ticket:migrated
Triggered when a ticket is migrated to a different team.
Additional payload:
Comment events
ticket:comment:added
Triggered when a comment is added to a ticket.
ticket:comment:updated
Triggered when a comment on a ticket is updated.
ticket:comment:deleted
Triggered when a comment is deleted from a ticket.
ticket:comment:reaction:added
Triggered when a reaction is added to a ticket comment.
ticket:comment:reaction:removed
Triggered when a reaction is removed from a ticket comment.
CSAT events
ticket:csat:sent
Triggered when a CSAT survey is sent for a ticket.
Additional payload:
ticket:csat:received
Triggered when a CSAT survey response is received.
Additional payload:
SLA events
ticket:sla:breached
Triggered when an SLA breach is detected on a ticket.
ticket:sla:breach_warning
Triggered when an SLA breach warning is detected on a ticket.
Event processing
Automatic event generation
When aticket:updated
event is processed, the system automatically analyzes the changes and generates appropriate specific events:
- Status change detection: Compares
ticket.status.uid
withpreviousTicket.status.uid
- Priority change detection: Compares
ticket.priority.uid
withpreviousTicket.priority.uid
- Assignment change detection: Compares
ticket.assignedAgent.uid
withpreviousTicket.assignedAgent.uid
- Custom field change detection: Analyzes custom field values for additions, removals, and changes
- Tag change detection: Compares tag sets between current and previous ticket states
Message size management
Ticket events can contain large amounts of data. The system automatically:- Monitors payload size (256KB limit)
- Truncates large content fields when necessary
- Replaces truncated content with “Payload too large. Use API instead”
- Logs truncation events for monitoring
Integration examples
Handling ticket creation
Handling status changes
Custom field monitoring
Best practices
- Event filtering: Use platform message attributes to filter for specific event types
- Idempotency: Use
eventId
to ensure idempotent processing - Error handling: Implement proper retry logic for failed event processing
- Large payloads: For truncated payloads, use the API to fetch complete data
- Performance: Process events asynchronously to avoid blocking ticket operations
Event frequency
Ticket events are high-frequency events, especially in active organizations. Consider:- Implementing rate limiting for downstream systems
- Using batch processing for non-critical integrations
- Filtering events at the platform subscription level to reduce unnecessary processing