Recent unversioned changes

Some changes may need to be made across multiple versions and therefore are not considered to be released under any one version. We place all of these recent changes here.

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 will no longer return statistics

❗️

Breaking change

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 now 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 now 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 automaticaly 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

❗️

Breaking change

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:

Changing id's to no longer be unique across all workspaces

❗️

Breaking change

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 in late February — 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.