Need to figure out why the Open Messaging API keeps rejecting our structured message payloads. The admin UI shows the conversation thread populating fine with plain text, but pushing quick replies or card layouts through the REST endpoint throws a 400 Bad Request. We’ve got the OAuth token scoped correctly and the conversation ID matches what the supervisor dashboard displays.
Here is the exact payload being sent:
{
“to”: { “id”: “conv-12345”, “type”: “conversation” },
“content”: [
{
“type”: “quickReply”,
“title”: “Select an option”,
“replies”: [
{ “id”: “opt1”, “title”: “Billing” },
{ “id”: “opt2”, “title”: “Support” }
]
}
]
}
Tried sending this directly to POST /api/v2/conversations/messages with application/json headers. The response consistently returns error_code invalid_message_content. Switched to a card payload with nested actions, same result. Checked the payload against the OpenAPI spec. Everything looks aligned. The routing configuration handles the initial text message without issues, but the structured format breaks immediately. We’ve tested with different conversation states. Active, waiting, and closed. All return the same 400 response. Sometimes the gateway logs show a 202 accepted. Message just sits there. Never renders in the guest client.
The admin interface doesn’t flag any schema validation errors when configuring the bot flow, so the issue has to be in how the API parses the nested objects. Wondering if there is a specific content_type header requirement or a version mismatch in the message schema. The platform SDK docs mention a structured flag, but that’s only for the desktop client integration. Need the exact JSON structure that the Open Messaging endpoint actually accepts for interactive elements.