Unversioned Changes
Some changes may need to be made across multiple versions and therefore are not considered to be released under any one version. You can find details of those changes here.
Breaking changes listed below are prepended with a ❗️symbol. For more details on the Intercom API policy around breaking changes see the details on the API Changelog information page
February 2024
Ticket States
Retrieving custom ticket states is available in versions 2.9, 2.10, and Unstable versions of the Tickets API.
Two states have been added:
ticket_state_internal_label: The state the ticket is currently in, in a human readable form. This is only visible within Intercom to teammates.ticket_state_external_label: The state the ticket is currently in, in a human readable form. This is visible to customers and can be viewed in the Messenger, Email, and Tickets portal.
Email Domains
The email_domain attribute has been added to the Contacts object in versions 2.0 and above.
April 2023
❗️Conversation Part IDs are not unique across all workspaces
As flagged in a previous update, we're making changes to our databases and models, and as a result, the id of a conversation_part will no longer be unique across all workspaces. We're continuing to make this change for other models, and we urge you to make the change for all identifiers which don't consider the workspace_id/app_id.
Previous updates
Supported HTML in Articles
From now on, additive changes to the HTML content returned by the Articles model will not be considered a breaking change. We will not be introducing new API versions when adding new supported HTML elements or attributes.
Removing element support or changing its shape in a way that causes previously supported HTML to become unsupported will still constitute a breaking change, and a new API version will be introduced in such cases.
We encourage all API consumers reading the contents of the Articles model response to handle any valid HTML in the article body, not just the subset defined in the supported HTML specification. This will ensure your code is resilient in handling any new HTML elements or attributes we may support in the future.
❗️Listed Articles no longer return statistics
Articles which have been listed will no longer return a statistics object. In order to get these statistics, you will now have to take the id of the article you want to fetch the statistics object for, and retrieve the article individually.
Tables and Horizontal Rules are supported as Article HTML content
Articles now support both Tables and Horizontal rules. This will mean they will show in the Articles model, and can be added within the body of an Article when creating or updating these using the valid HTML. The Articles endpoint is available from V2.1 upwards.
Text component headers are bold for Messenger Canvas Kit apps
When a Text component which has a style of header is now rendered in a Messenger Canvas Kit app on web, the text will automatically be bold without need for markdown. This is in an effort to better style the text based on its given purpose, and makes for greater content accessibility.
❗️Obfuscating Twitter data within Conversation objects
We've been informed by Twitter that changes to their API policies mean we're no longer compliant. As a result, we've obfuscated several fields for conversations received from Twitter. This affects all versions of the API for the following models:
❗️IDs are not unique across all workspaces
To improve performance, we're making changes to our databases and models, and as a result, id will no longer be unique across all workspaces.
This means that the only unique identifier you should use is the workspace_id/app_id. If you've mapped any data to id's other than the workspace_id/app_id, then you should ensure that you are providing the workspace_id/app_id alongside, or in place of, other id's.
We made the change for conversation identifiers — meaning the id of a conversation will only be unique to a given workspace. We plan to do the same for the id of a conversation_part some time in the future. We are also likely to apply this across several models in the future so we urge you to make the change for all identifiers which don't consider the workspace_id/app_id.