General FAQs

Q: What are System Events (SysEvents)?

A: System Events are bot-initiated conversations that occur without a direct user message. They include:

• Notifications - Proactive messages sent by the bot (e.g., approval updates, ticket updates, password expiry alerts, campaign messages, ambient agent notifications)
• Ticket Interception - The bot automatically intercepts a newly created ticket and reaches out to the user to help resolve it
• Channel Interception - The bot detects a question in a Slack/Teams channel and proactively offers help

Previously, Data API only included conversations where a user directly engaged with the bot (DM conversations). With this update, all system-triggered conversations are now included.

Q: When will these changes go live?

A: Changes will start to reflect in the Data API starting April 1, 2026. There is no change to existing API endpoints or authentication - the new data will automatically appear in the existing entities.

Q: Will historical data be backfilled?

A: No. Historical backfill is not possible. Data before April 1, 2026 will only contain user-engaged conversations as it exists today. The new SysEvent data is only available going forward from the rollout date.

Q: Which Data API entities are affected?

A: Four entities are updated:

1. /conversations - Now includes all system-triggered conversations (not just user-engaged ones). All Ticket & Channel Interceptions with & without any bot reach out will be part of conversations entity
2. /interactions - Now includes bot messages (bot actor interactions) from SysEvent conversations (notifications, interception reachouts)
3. /plugin_calls - Now includes plugin calls triggered by SysEvents (e.g., interception-related plugins). Interception conversations without any bot reach out will not have plugin calls in the plugin_calls entity
4. /plugin_resources - Now includes resources from SysEvent-triggered plugin calls

Q: Will this break my existing Data API integrations or downstream pipelines?

A: The API schema and endpoints remain unchanged. However, because the volume of data returned increases significantly, any downstream pipelines, reports, or dashboards that aggregate across all conversations or interactions may see inflated numbers. We recommend reviewing your queries and filters to ensure they account for the new SysEvent data. See the volume impact FAQ below for details.

Data Volume Impact

Q: How much will the data volume increase?

A: The expected volume increases are:

Volume changes for /plugin_calls and /plugin_resources vary significantly across organizations depending on whether Ticket/Channel Interception is enabled and the volume of interceptions.

Please note : TTL for data API is 30 days. 

Q: How can I filter out SysEvent data if I only want user-engaged conversations?

A: Use the route field in the /conversations entity. To get only user-initiated DM conversations (matching pre-update behavior), filter where route = 'DM'. SysEvent conversations will have routes such as Notification, Ticket, or Channel.

Conversations Entity

Q: What is changing in the Conversations entity?

A: The scope and definition of the Conversations entity is expanding from user-engaged conversations only to all conversations (system-triggered + user-engaged). This includes:

• All Notifications (approval updates, ticket updates, campaign messages, ambient agent alerts, etc.)
• All Ticket Interception conversations (with and without bot reachout)
• All Channel Interception conversations (with and without bot reachout)
• All DM conversations (unchanged from current behavior)

Q: What new fields are being added to the Conversations entity?

A: Two new columns are added:

• type — Captures the type of the SysEvent conversation (e.g., CONVERSATION_TYPE_APPROVAL_UPDATE_NOTIFICATION, CONVERSATION_TYPE_TICKET_INTERCEPTION, CONVERSATION_TYPE_CHANNEL_INTERCEPTION, etc.). This is only populated for newly added system-triggered conversations.
• detail — Captures metadata for the SysEvent conversation. The contents vary by type (e.g., ticket_id for ticket notifications, campaign_id and campaign_name for comms notifications, usecase_id and usecase_name for ambient agent notifications).

Q: What are all the possible values for the type field?

A: The following conversation types are available:

Q: What happens with notifications that were sent before the rollout but engaged with after?

A: For legacy notifications sent before the rollout but first engaged after April 1, 2026:

• They will appear with route = Notification (same as current behavior)
• The type and detail columns will be Null (empty)
• This helps distinguish them from new SysEvent notifications which will have type and detail populated
• This transition state will persist for approximately 30 days after rollout, after which all notification data will have type and detail values populated.

Q: Will primary_domain be populated for all SysEvent conversations?

A: No. primary_domain will have 0% coverage for Notifications. For DM, Ticket Interception, and Channel Interception conversations, primary_domain will be populated wherever detected, same as the current behavior.

Q: How to determine Ticket/Channel Interceptions without bot reachout?

A: These non-reachout interception events will not have any corresponding records in the /interactions entity, which helps you determine whether the bot actually reached out.

Interactions Entity

Q: What is changing in the Interactions entity?

A: The Interactions entity will now include bot messages from SysEvent conversations - i.e., the notification messages and interception reachout messages sent by the bot. These are exposed the same way as other bot actor interactions.

Q: What will the actor and type values be for SysEvent interactions?

A: All new SysEvent interactions will have:

• actor = bot
• type = INTERACTION_TYPE_BOT_MESSAGE
• label = Null

Q: Will parent_interaction_id be populated for SysEvent interactions?

A: It is expected to be Null for SysEvent interactions, since these are system-initiated messages with no prior user interaction. However, approximately <0.01% of SysEvent messages may have a non-null parent_interaction_id due to upstream known log gaps (log rotate issue). These will not have referential integrity with user actor interactions.

Q: Can the detail (content) field be empty for SysEvent interactions?

A: Yes. Approximately 0.05% of SysEvent messages may have null content in the detail field. This occurs when the bot serves blank messages in the Assistant for those cases.

Plugin calls Entity

Q: What is changing in the Plugin Calls entity?

A: The Plugin Calls entity will now include plugin calls triggered by SysEvents - for example, plugins executed during Ticket or Channel Interception workflows. Also, Interception conversations without any bot reach out will not have plugin calls in the plugin_calls entity

Q: How does interaction_id work for SysEvent plugin calls?

A: This is an important behavioral change. Previously, all plugin calls mapped to user actor interaction IDs. With this update, new SysEvent plugin calls will map to bot actor interaction IDs, since these plugins are triggered without any user interaction.

Q: What happens when a SysEvent plugin requires user input?

A: For plugins that require user input (e.g., an action plugin within a notification):

1. An initial plugin call record is created with interaction_id matching the bot actor interaction and used = False (waiting for user response)
2. Once the user interacts, a new plugin call record is created with interaction_id matching the user actor interaction, and the used field reflects whether the plugin successfully completed.

Plugin resources Entity

Q: What is changing in the Plugin Resources entity?

A: The Plugin Resources entity will now include resources from SysEvent-triggered plugin calls (e.g., tickets created during interception workflows). The daily volume increases by approximately 10%, varying by organization.

Q: How does interaction_id work for SysEvent plugin resources?

A: Similar to Plugin Calls, the interaction_id for SysEvent plugin resources maps to the bot actor interaction ID (the notification or interception message), since there is no initial user interaction.

Q: Can interaction_id be Null in Plugin Resources?

A: Yes. For certain Channel Interception scenarios where the bot files a ticket directly without reaching out to the user, the interaction_id in Plugin Resources will be Null. This is expected behavior for these auto-filed tickets.

Q: Is plugin_call_id always populated for SysEvent plugin resources?

A: plugin_call_id is populated wherever applicable, same as for user-initiated plugin resources. However, tickets created directly by the bot (without going through a plugin call) will not have a plugin_call_id.

Others

Q: Are there any known data gaps in the detail field for Conversations?

A: Yes, there are a few known gaps depending on the conversation type:

• Approval Notifications: 2–5% may have missing type, source, and domain values due to unavailable metadata if these approval records are not polled.
• Comms Notifications: campaign_name is only available for campaigns created after February 20, 2026. A small fraction (<0.2%) of preview messages will not have a campaign_id
• Events Notifications: usecase_id and usecase_name are not guaranteed for all events notifications, as this type includes a mix of legacy Message API notifications and Creator Studio events

Ambient Agent Notifications: Coverage is expected to be near 100%, with rare exceptions on test notifications sent via Compound Action Tool