Skip to content
Home/
/
Changelog (Preview)

Changelog (Preview)

Preview API

The Preview API provides early access to new capabilities we're actively developing. It's suitable for production use, and we're continuing to refine it based on customer feedback. We may make iterative improvements to Preview endpoints, including adding new fields or refining existing ones. When changes are not backward-compatible, we'll communicate them in advance.

For changes that have been updated across all versions, see the Unversioned changes page.

There are breaking changes in this version, which are detailed below.

Side Conversations API

A new GET /conversations/{id}/side_conversations endpoint is now available for retrieving side conversations (internal teammate threads) associated with a conversation. Results are paginated and include the full conversation parts for each side conversation.

New Endpoint:

Query Parameters:

  • page (optional) - Page number of results to return (default: 1)
  • per_page (optional) - Number of side conversations per page, between 1 and 50 (default: 25)

Example Response:

{
  "type": "side_conversation.list",
  "side_conversations": [
    {
      "side_conversation_id": "456",
      "conversation_parts": [
        {
          "type": "conversation_part",
          "id": "789",
          "part_type": "comment",
          "body": "<p>Internal note about this issue</p>",
          "author": {
            "type": "admin",
            "id": "123",
            "name": "Jane Example",
            "email": "jane@example.com"
          }
        }
      ],
      "total_count": 1
    }
  ],
  "total_count": 1,
  "pages": {
    "type": "pages",
    "page": 1,
    "per_page": 25,
    "total_pages": 1
  }
}

OAuth Scope: read_conversations

Company Activity Tracking via API

The POST /companies and PUT /companies/{id} endpoints now accept an update_last_request_at boolean parameter. When set to true, the company's last_request_at field is updated to the current time.

This is useful for workspaces that manage companies via the REST API and need to keep the "Last seen" value up to date. Requires the write_users_companies OAuth scope.

Search Activity Logs API

A new POST /admins/activity_logs/search endpoint is now available for searching and filtering admin activity logs. This provides a dedicated search endpoint with event type filtering capabilities.

New Endpoint:

Request Body Parameters:

  • created_at_after (optional) - Start date as a UNIX timestamp (defaults to 30 days ago)
  • created_at_before (optional) - End date as a UNIX timestamp
  • event_types (optional) - Array of event type strings to filter by
  • page (optional) - Page number of results to return (default: 1)
  • per_page (optional) - Number of results per page, between 1 and 250 (default: 20)

Example Request:

{
  "created_at_after": "1677253093",
  "created_at_before": "1677861493",
  "event_types": ["app_name_change", "message_state_change"]
}

Use the GET /admins/activity_log_event_types endpoint to retrieve all valid event type values.

This endpoint requires the read_admins OAuth scope.

Content Snippets API

New endpoints to manage content snippets via the public API. Content snippets are reusable pieces of content that power Fin (AI agent) and Copilot responses.

Endpoints:

  • GET /content_snippets - List all content snippets (paginated)
  • GET /content_snippets/{id} - Retrieve a single content snippet
  • POST /content_snippets - Create a new content snippet
  • PUT /content_snippets/{id} - Update an existing content snippet

OAuth Scope: read_write_content_snippets

Example Request:

GET /content_snippets

Example Response:

{
  "type": "list",
  "data": [
    {
      "type": "content_snippet",
      "id": "123",
      "title": "How to reset your password",
      "locale": "en",
      "json_blocks": [
        { "type": "paragraph", "text": "Navigate to Settings > Security > Reset password." }
      ],
      "chatbot_availability": 1,
      "copilot_availability": 1,
      "created_at": 1663597223,
      "updated_at": 1663597223
    }
  ],
  "total_count": 1,
  "page": 1,
  "per_page": 50,
  "total_pages": 1
}

Real-Time Team Metrics

A new GET /teams/{team_id}/metrics endpoint is now available, providing real-time per-admin conversation metrics (open, idle, snoozed counts) for a given team. This is designed for workforce management integrations that need to monitor agent workload in real time.

Endpoint: GET /teams/{team_id}/metrics

Path Parameters:

  • team_id - The ID of the team to retrieve metrics for. Use GET /teams to list available team IDs.

Optional Parameters:

  • idle_threshold - Seconds after which an open conversation is considered idle (default: 1800, clamped to 1–86400).

Example Request:

GET /teams/42/metrics

Example Response:

{
  "type": "team_metric.list",
  "data": [
    {
      "type": "team_metric",
      "admin_id": "123",
      "open": 5,
      "idle": 2,
      "snoozed": 1
    }
  ]
}

This endpoint requires the real-time monitoring feature to be enabled for your workspace and the read_admins OAuth scope.

For complete documentation, see the Team Metrics API Reference.

Email History in Conversation Source

The GET /conversations/{id} endpoint now supports an include_email_history query parameter. When set to true, the source object of the conversation (email) will include an email_message_metadata field containing:

  • message_id — the unique identifier from the email's Message-ID header
  • subject — the subject of the email
  • email_address_headers — a list of an email address headers
  • history — the HTML content of any quoted or forwarded email history from the initial inbound message

Updated Endpoint:

  • GET /conversations/{id}?include_email_history=true — returns email_message_metadata in the source object

Note: The history is only available for the conversation source (initial part), not for individual conversation parts. This parameter is not available on list/search endpoints.

List Deleted Conversations API

You can now retrieve a list of deleted conversation IDs and their deletion timestamps using the new GET /conversations/deleted endpoint.

Try Listing Deleted Conversations
Loading...

GET /fin_voice/conversation/{conversation_id} added

Added missing endpoint for retrieving Fin Voice calls associated with a conversation ID. Also backfilled to v2.15.

Fin Agent API: New replying status for intermediate reply events

The fin_replied webhook event now uses a replying status for intermediate reply parts, and a separate fin_status_updated event with awaiting_user_reply fires as a "done" signal when Fin has finished replying. This replaces the previous behavior where every fin_replied event had status: awaiting_user_reply, making it impossible to distinguish intermediate replies from the final one.

Before:

fin_replied (status: awaiting_user_reply) — part 1
fin_replied (status: awaiting_user_reply) — part 2
fin_replied (status: awaiting_user_reply) — part 3

After:

fin_replied (status: replying) — part 1
fin_replied (status: replying) — part 2
fin_replied (status: replying) — part 3
fin_status_updated (status: awaiting_user_reply) — done signal

What changed:

  • fin_replied event: status enum now includes replying (new default for intermediate replies) and awaiting_user_reply (legacy)
  • fin_status_updated event: status enum now includes awaiting_user_reply in addition to escalated, resolved, and complete

Clients should update their integrations to listen for the fin_status_updated event with status: awaiting_user_reply as the signal that Fin is done replying and the user can respond.

Activity Log Event Types API

A new endpoint lets you retrieve all possible event type values for admin activity logs. Use these values to understand what actions are trackable and to filter results when querying the Activity Logs API.

New Endpoint:

  • GET /admins/activity_log_event_types - List all activity log event types

Example Response:

{
  "type": "activity_log_event_type.list",
  "event_types": [
    "admin_login_success",
    "admin_logout",
    "app_name_change",
    "message_state_change"
  ]
}

OAuth Scope Required: Read admins and teammates

For complete documentation, see the Activity Log Event Types API Reference.

Conversations API: retain_metrics parameter for conversation deletion

The Delete a conversation endpoint now supports a retain_metrics query parameter that controls how conversation data is deleted:

  • retain_metrics=true (default): Deletes the conversation while retaining reporting data.
  • retain_metrics=false: Deletes the conversation and all associated reporting data.
Required scope for retain_metrics=false

Using retain_metrics=false requires the delete_conversations_and_metrics OAuth scope. See OAuth Scopes for details.

Example Request:

curl -X DELETE https://api.intercom.io/conversations/123?retain_metrics=false \
  -H 'Authorization: Bearer <YOUR_ACCESS_TOKEN>' \
  -H 'Accept: application/json' \
  -H 'Intercom-Version: Preview'

For more info, see this help center article.

Folder Management API

A new top-level Folders API is now available at /folders for organizing content into hierarchical folder structures.

New endpoints:

  • GET /folders — List all folders (supports pagination and parent_folder_id filter)
  • POST /folders — Create a new folder
  • GET /folders/{id} — Retrieve a folder
  • PUT /folders/{id} — Update a folder
  • DELETE /folders/{id} — Delete a folder (must be empty)

Article and Internal Article changes:

  • A folder_id field has been added to article and internal article responses, as well as create and update request payloads, allowing you to organize articles into folders.
  • The /internal_articles/search endpoint's folder_id parameter now searches recursively through descendant folders.

Ticket state change tracking

The Ticket object now includes a previous_ticket_state_id field that returns the ID of the ticket's previous state. This enables tracking ticket state transitions for reporting and compliance. The field returns null when no state change history exists.

Company Notes API

You can now create notes on company records via the API using POST /companies/{company_id}/notes, mirroring the existing contact notes functionality. The request and response format is identical to contact notes, with an optional admin_id parameter that defaults to the token owner. Notes are polymorphic — a single note belongs to either a contact or a company, never both.

Admin role now included in API responses

The admin object returned by GET /admins, GET /admins/{id}, GET /me, and PUT /admins/{id}/away now includes a role attribute when the admin has a role assigned. The role object contains the role id and name.

Example:

{
  "type": "admin",
  "id": "1295",
  "name": "Joe Example",
  "role": {
    "type": "role",
    "id": "456",
    "name": "Support Agent"
  }
}

Note: Admins with custom per-user permissions (no role assigned) will not have the role field.

Conversations API: display_as parameter behavior

The display_as query parameter in the Retrieve Conversation and List Conversation Parts endpoints now affects both the body and subject fields of conversation messages when set to plaintext. By default, both fields are returned in HTML format.

Conversation Webhook Serialization Alignment

Conversation webhook payloads now use the same serialization format as API responses:

  • Statistics date fields (first_contact_reply_at, first_assignment_at, first_admin_reply_at, first_close_at, last_assignment_at, last_assignment_admin_reply_at, last_contact_reply_at, last_admin_reply_at, last_close_at) now return Unix timestamp integers instead of ISO8601 strings.
  • body and subject fields now return plain text instead of HTML.

Data Connectors API

We've added a new Data Connectors API that lets you create, update, delete, and list your data connectors, plus view their execution history. Data connectors allow you to make HTTP requests to external APIs from Intercom workflows and AI agents.

Endpoints:

  • POST /data_connectors - Create a new data connector
  • PATCH /data_connectors/{id} - Update a data connector (fields, state transitions)
  • DELETE /data_connectors/{id} - Delete a data connector
  • GET /data_connectors - List all data connectors (paginated)
  • GET /data_connectors/{id} - Retrieve a single data connector with full detail
  • GET /data_connectors/{id}/execution_results - List execution results
  • GET /data_connectors/{id}/execution_results/{id} - Retrieve a single execution result

Key Features:

  • Create in draft: New connectors start in draft state — configure URL, headers, data inputs, and audiences before publishing
  • Audience targeting: Control which user types (leads, users, visitors) can trigger the connector
  • Safe deletion: Returns 409 if the connector is in use or not in draft state
  • Cursor-based pagination: Navigate through data connectors and execution results using starting_after and per_page
  • Filtering: Filter execution results by success, error_type, and time range
  • Opt-in bodies: Use include_bodies=true to include request/response bodies in execution results
  • Opt-in request URL: Use include_request_url=true to include the sanitised request URL

OAuth Scope Required: Read data connectors (read-only) or Read and write data connectors (create/update/delete)

For complete documentation and examples, see the Data Connectors API Reference.

New Data Connector execution webhook topic

You can now receive real-time notifications when Data Connector actions complete execution using the new data_connector.execution.completed webhook topic. This webhook provides operational visibility into connector execution outcomes, including success/failure status, HTTP response codes, error categorization, and execution timing. See the webhook models for details on how to subscribe to execution events.

Macros API

We've added a new Macros API that provides programmatic access to saved replies (macros) in Intercom. This API enables external applications to retrieve and display your team's pre-written responses, making it easier to integrate Intercom macros with third-party tools and workflows.

New Endpoints:

  • GET /macros - List all available macros with pagination
  • GET /macros/{id} - Retrieve a specific macro by ID

Key Features:

  • Cursor-based pagination: Navigate through large sets of macros efficiently using the starting_after parameter with Base64-encoded cursors
  • Smart placeholder transformation: Macros containing Intercom placeholders (e.g., {{user.name}}) are automatically transformed to XML-like attributes (<attribute key="user.name"/>) for easier parsing
  • Flexible filtering: Use the updated_since parameter to retrieve only recently modified macros
  • Team visibility controls: Respects macro visibility settings, showing only macros available to the authenticated user's teams
  • Channel availability: Each macro indicates where it can be used (inbox, messenger, or both)

OAuth Scope Required: READ_CONVERSATIONS

Use Cases:

  • Integration with training platforms like Solidroad for customer service simulations
  • Building custom macro management interfaces
  • Exporting macros for documentation or backup purposes
  • Analyzing macro usage and content across your organization

Example Request:

curl -X GET https://api.intercom.io/macros?per_page=10 \
  -H 'Authorization: Bearer <YOUR_ACCESS_TOKEN>' \
  -H 'Accept: application/json' \
  -H 'Intercom-Version: Preview'

Example Response:

{
  "type": "list",
  "data": [
    {
      "type": "macro",
      "id": "123",
      "name": "Order Status Update",
      "body": "<p>Hi <attribute key=\"user.name\" default=\"there\"/>, your order is ready!</p>",
      "body_text": "Hi there, your order is ready!",
      "created_at": "2025-07-17T11:18:08.000Z",
      "updated_at": "2025-07-17T15:30:24.000Z",
      "visible_to": "everyone",
      "visible_to_team_ids": [],
      "available_on": ["inbox", "messenger"]
    }
  ],
  "pages": {
    "type": "pages",
    "per_page": 10,
    "next": {
      "starting_after": "WzE3MTk0OTM3NTcuMCwgIjEyMyJd"
    }
  }
}

Important Notes:

  • This API is currently available in the Preview version only
  • Placeholders in macro bodies are transformed from Intercom format to XML-like attributes
  • The pagination cursor encodes [updated_at, id] for stable ordering
  • Maximum 150 macros can be retrieved per request

For complete documentation and more examples, see the Macros API Reference.

New WhatsApp Message status API

The WhatsApp Message status API is now available in the Preview version. This endpoint returns paginated status events for WhatsApp messages sent via the Outbound module, providing information about delivery state and related message details.

Enforcement of ticket permissions on the Conversations API

Starting in early August 2024, accessing a ticket directly through the Conversations API will requires the "Read tickets" or "Write tickets" scope, as appropriate. When listing conversations or searching conversations, tickets will only be returned in the results if the caller has the "Read tickets" scope.

Breaking permission changes

Previously, tickets were accessible through the Conversations API using only the "Read conversations" or "Write conversations" scope(s). Any apps relying on this behaviour will need to add the appropriate ticket permission, and have users reauthenticate.

New Searchable Contact Attribute

We added formatted_phone as a searchable attribute for contacts. This is the contact's phone number normalized to the E164 format.

Reporting Data Export API: qualified_id for Attribute Disambiguation

The Reporting Data Export API now includes a qualified_id field in the get_datasets response to uniquely identify attributes across different types.

Problem Solved: Custom attributes can have the same name across different types (e.g., a "Brand" attribute might exist for both user custom data and conversation custom data). Previously, using just the id field could result in ambiguous attribute selection.

New Field: The qualified_id field uses a namespaced format: "type.name" (e.g., "people.Brand", "conversation.Brand").

Available Prefixes:

  • people - User custom data attributes
  • company - Company custom data attributes
  • conversation - Conversation custom data attributes
  • ticket - Ticket attributes
  • system - System-defined attributes

Example Response:

{
  "type": "list",
  "data": [
    {
      "id": "conversation",
      "name": "Conversation",
      "attributes": [
        {
          "id": "Brand",
          "qualified_id": "people.Brand",
          "name": "Brand"
        }
      ]
    }
  ]
}

Usage: When calling the enqueue endpoint, you must use qualified_id values in the attribute_ids array. The simple id is no longer accepted — use the qualified_id from the get_datasets response to ensure unambiguous attribute selection.

Previous page
Next page