***

title: Notifications data via API - FAQ
slug: ai-assistant/analytics-performance/data-api/notifications-data-via-api-faq
--------------------------------------------------------------------------------

<Callout intent="info">
  Starting **April 1, 2026**, the Data API is being updated to include **System Events (SysEvents)** - such as Notifications, Ticket Interception, and Channel Interception — across four entities: `/conversations`, `/interactions`, `/plugin_calls`, and `/plugin_resources`. This FAQ addresses common questions about these changes for customers and GTM teams.
</Callout>

# 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:

| Entity              | Approx. Avg Increase |               |
| ------------------- | -------------------- | ------------- |
| `/conversations`    | **7–8x**             | Varies by org |
| `/interactions`     | **5–6x**             | Varies by org |
| `/plugin_calls`     | **\~25%**            | Varies by org |
| `/plugin_resources` | **\~10%**            | Varies by org |

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:

| Type                                               | Detail Fields                           |
| -------------------------------------------------- | --------------------------------------- |
| `CONVERSATION_TYPE_APPROVAL_UPDATE_NOTIFICATION`   | `type`, `source`, `domain`              |
| `CONVERSATION_TYPE_COMMS_NOTIFICATION`             | `campaign_id`, `campaign_name`          |
| `CONVERSATION_TYPE_AMBIENT_AGENT_NOTIFICATION`     | `usecase_id`, `usecase_name`            |
| `CONVERSATION_TYPE_EVENTS_NOTIFICATION`            | `usecase_id`, `usecase_name`            |
| `CONVERSATION_TYPE_TICKET_UPDATE_NOTIFICATION`     | `ticket_id`                             |
| `CONVERSATION_TYPE_TICKET_WAITING_NOTIFICATION`    | `ticket_id`                             |
| `CONVERSATION_TYPE_TICKET_WATCHER_NOTIFICATION`    | `ticket_id`                             |
| `CONVERSATION_TYPE_TICKET_NUDGE_NOTIFICATION`      | `ticket_id`                             |
| `CONVERSATION_TYPE_TICKET_INTERCEPTION`            | `ticket_id`, `content`                  |
| `CONVERSATION_TYPE_CHANNEL_INTERCEPTION`           | `channel_id`, `channel_name`, `content` |
| `CONVERSATION_TYPE_EXPIRED_PASSWORD_NOTIFICATION`  | None                                    |
| `CONVERSATION_TYPE_EXPIRING_PASSWORD_NOTIFICATION` | None                                    |
| `CONVERSATION_TYPE_LOCKED_ACCOUNT_NOTIFICATION`    | None                                    |
| `CONVERSATION_TYPE_CSAT_NOTIFICATION`              | None                                    |
| `CONVERSATION_TYPE_BOT_DIGEST_NOTIFICATION`        | None                                    |
| `CONVERSATION_TYPE_NUDGE_NOTIFICATION`             | None                                    |
| `CONVERSATION_TYPE_PROMOTION_NOTIFICATION`         | None                                    |
| `CONVERSATION_TYPE_SELF_SERVE_ALERT_NOTIFICATION`  | None                                    |
| `CONVERSATION_TYPE_UNSPECIFIED_SYS_EVENT`          | None                                    |

### 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*](https://docs.moveworks.com/ai-assistant/analytics-performance/data-api/data-api-known-gaps-and-future-roadmap)). 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