Something is acting up with our email parsing and canned responses. We’ve got a flow that uses a script to update the draft reply before the agent sends it. The script calls the PUT /api/v2/conversations/emails/{conversationId}/messages/draft endpoint to inject a specific HTML template based on the routing rule.
The problem is that the HTML formatting for the signature stripping isn’t working right. When the API updates the draft, it’s stripping out the <div> tags and messing up the line breaks in the body. The agent sees a wall of text instead of the clean template.
The request body looks like this:
{
"text": "Hello, thank you for contacting us.",
"html": "<html><body><p>Hello, thank you for contacting us.</p><br><div class='sig'>Support Team</div></body></html>"
}
It’s not returning an error code, just the wrong output in the UI. We’ve tried simplifying the HTML, but the result is the same. This is breaking the professional look of our emails in prod.
Maybe the issue is how the HTML is being escaped before it hits the endpoint (it’s a common trap where the system double-encodes the tags and breaks the rendering in the agent’s UI). The PUT /api/v2/conversations/emails/{conversationId}/messages/draft endpoint expects a very specific string format for the body, and if you’re sending the HTML as part of a larger JSON payload without ensuring the content-type is handled correctly (or if there are stray characters in the signature template), the email client often strips the styles or renders them as raw text. From what I’ve seen, the most reliable way to handle this is to wrap the entire draft content in a clean <html><body> structure and ensure the text field in the request body is a single, contiguous string (no accidental newlines that the JSON parser might choke on). Try sending the payload exactly like this to see if the formatting sticks:
{
"text": "<html><body><p>Your main message here</p><br><p style='font-size:12px; color:#666;'> Regards,<br>Support Team (Signature)</p></body></html>"
}
It’s also worth checking if the script is accidentally overwriting the draft with a plain text version (which would definitely kill any HTML formatting) instead of updating the existing draft state. Just a hunch, but if the script runs too quickly after the conversation is routed (before the draft object is fully initialized on the backend), you might get some unpredictable behavior with the HTML rendering.
PUT /api/v2/conversations/emails/{conversationId}/messages/draft
{
"text": "<html><body>Your content here</body></html>"
}
The point regarding encoding in the earlier reply is valid. However, we’ve seen similar formatting failures in other community posts when the HTML payload exceeds specific character limits. Is the template being injected particularly large? This could negatively impact agent adoption if the UI becomes unresponsive during the draft phase.
Oh, this is… a bit of a worry (400, naturally). I remember hitting a similar wall ages ago whilst we were trying to organise our Rails middleware for Zoom Contact Center webhooks. We thought we’d nailed the formatting, but the content would randomly strip out styles when the payload was too large (413, obviously). The real danger here is that if you’re updating the draft frequently via PUT /api/v2/conversations/emails/{conversationId}/messages/draft, you might hit rate limits (429, of course) if the script triggers on every keystroke or event.
We ended up using Sidekiq to debounce those updates so we didn’t hammer the API. If you’re just doing a one-off injection, you’re probably fine, but it’s worth checking if there’s any race condition between the agent typing and the API call (409, naturally). Fwiw, we had to change the colour of our alert banners twice because the HTML rendering was so temperamental.