Table support in conversation replies is available only on the unreleased Preview API version, and it is not yet enabled for all workspaces. Until your workspace has access and you're calling on a version that includes this change, <table> markup in a reply body continues to be flattened to plain text, as it is today.
When you send a reply to POST /conversations/{id}/reply or POST /tickets/{id}/reply with an HTML <table> in the body, the table is preserved as a real, structured table in the conversation instead of being flattened into a single paragraph of concatenated cell text. This applies to both message_type: comment and message_type: note. On a ticket, message_type: comment is rejected for tracker tickets and for back-office tickets that are not shared with the customer — those accept message_type: note only. That restriction is existing ticket-reply behaviour and is not specific to tables.
Over time we may add support for new table elements or attributes. This will not constitute a breaking change — we advise client code to tolerate markup it doesn't yet recognize. Removing element support, or otherwise changing the API in a way that causes previously supported HTML to become unsupported, will be considered a breaking change.
| Tag | What does it do? | Additional details |
|---|---|---|
<table> | Table | Defines the table. |
<thead> <tbody> | Row grouping | Recognized and used to group rows. |
<tr> | Row | Defines a table row. |
<td> | Cell | Defines a standard data cell. |
<th> | Header cell | Defines a header cell. |
colspan rowspan | Cell spanning | Supported on <td> and <th>. |
A table-bearing reply is checked against these limits before anything is converted:
| Limit | Value |
|---|---|
| Rows per table | 200 |
Columns per table (counting colspan) | 50 |
| Tables per reply | 20 |
Table cells per reply (counting colspan × rowspan expansion) | 10,000 |
If a reply exceeds any of these limits, the request is rejected outright with 400 Bad Request naming the limit that was exceeded. Nothing is silently truncated or partially converted — either the whole table structure is preserved, or the request fails validation up front. Resubmit with a smaller table, or split it across multiple replies, to work around this.
A <table> nested inside another <table> is not supported. If a reply body contains a nested table anywhere, the entire request is rejected with 400 Bad Request before any conversion happens. Flatten nested tables into a single table, or into separate tables, before sending the reply.
When a reply body contains a table, the processing path for the entire body changes — not just the table. The following apply to the whole reply, not only to content inside the table:
| Behavior | What do we do? |
|---|---|
slack:, discord:, and msteams: links anywhere in the body | Removed. Only http, https, mailto, and relative links survive in a table-bearing reply. |
<caption> text on a table | Not retained anywhere in the resulting conversation part. |
A link (<a href="...">) inside a heading (<h1>–<h6>) | The heading text is kept, but it stops being a link. |
An " entity inside an href | Truncates the URL at that point. Avoid encoded quotes in link destinations within a table-bearing reply. |