POST /messages

Default value: "application/x-www-form-urlencoded"

The channel or users receiving the message.

For channel messages, this is either the name or integer ID of the channel.

For direct messages, this is either a list containing integer user IDs or a list containing string Zulip API email addresses. The ID or email address of the user sending the message can be included in the list, but will be ignored by the server, unless the user sending the message is the only recipient of the message.

Changes: In Zulip 2.0.0, support for using user/channel IDs was added.

The topic of the message. Only required for channel messages ("type": "stream" or "type": "channel"), ignored otherwise.

Clients should use the max_topic_length returned by the POST /register endpoint to determine the maximum topic length.

Note: When "(no topic)" or the value of realm_empty_topic_display_name found in the POST /register response is used for this parameter, it is interpreted as an empty string.

When topics are required, this parameter can't be "(no topic)", an empty string, or the value of realm_empty_topic_display_name.

Changes: Before Zulip 10.0 (feature level 370), "(no topic)" was not interpreted as an empty string.

Before Zulip 10.0 (feature level 334), empty string was not a valid topic name for channel messages.

New in Zulip 2.0.0. Previous Zulip releases encoded this as subject, which is currently a deprecated alias.

Whether the message should be initially marked read by its sender. If unspecified, the server uses a heuristic based on the client name.

Changes: New in Zulip 8.0 (feature level 236).

The type of message to be sent.

"direct" for a direct message and "stream" or "channel" for a channel message.

Changes: In Zulip 9.0 (feature level 248), "channel" was added as an additional value for this parameter to request a channel message.

In Zulip 7.0 (feature level 174), "direct" was added as the preferred way to request a direct message, deprecating the original "private". While "private" is still supported for requesting direct messages, clients are encouraged to use to the modern convention with servers that support it, because support for "private" will eventually be removed.

Valid values:

• "channel"
• "private"
• "stream"
• "direct"

The content of the message.

Clients should use the max_message_length returned by the POST /register endpoint to determine the maximum message size.

For clients supporting local echo, the event queue ID for the client.

If passed, local_id is required.

If the message is successfully sent, the server will include local_message_id in the message event that the client with this queue_id will receive.

For clients supporting local echo, a unique string-format identifier chosen freely by the client.

If passed, queue_id is required.

If the message is successfully sent, the server will pass it back to the client without inspecting it as local_message_id in the message event that the client with the above queue_id will receive.