POST /typing

Notify other users whether the current user is typing a message.

Clients implementing Zulip's typing notifications protocol should work as follows:

Send a request to this endpoint with "op": "start" when a user starts composing a message.
While the user continues to actively type or otherwise interact with the compose UI (e.g. interacting with the compose box emoji picker), send regular "op": "start" requests to this endpoint, using server_typing_started_wait_period_milliseconds in the POST /register response as the time interval between each request.
Send a request to this endpoint with "op": "stop" when a user has stopped using the compose UI for the time period indicated by server_typing_stopped_wait_period_milliseconds in the POST /register response or when a user cancels the compose action (if it had previously sent a "start" notification for that compose action).
Start displaying a visual typing indicator for a given conversation when a typing op:start event is received from the server.
Continue displaying a visual typing indicator for the conversation until a typing op:stop event is received from the server or the time period indicated by server_typing_started_expiry_period_milliseconds in the POST /register response has passed without a new typing "op": "start" event for the conversation.

This protocol is designed to allow the server-side typing notifications implementation to be stateless while being resilient as network failures will not result in a user being incorrectly displayed as perpetually typing.

See the subsystems documentation on typing indicators for additional design details on Zulip's typing notifications protocol.

Changes: Clients shouldn't care about the APIs prior to Zulip 8.0 (feature level 215) for channel typing notifications, as no client actually implemented the previous API for those.

Support for displaying channel typing notifications was new in Zulip 4.0 (feature level 58). Clients should indicate they support processing channel typing notifications via the stream_typing_notifications value in the client_capabilities parameter of the POST /register endpoint.

Servers

https://{subdomain}.zulipchat.com/api/v1
{server}/api/v1
https://chat.zulip.org/api/v1

Request headers

Name	Type	Required	Description
`Content-Type`	String	Yes	The media type of the request body. Default value: "application/x-www-form-urlencoded"

Request body fields

Name	Type	Required	Description
`to[]`	Array	No	User IDs of the recipients of the message being typed. Required for the `"direct"` type. Ignored in the case of `"stream"` or `"channel"` type. Clients should send a JSON-encoded list of user IDs, even if there is only one recipient. Changes: In Zulip 8.0 (feature level 215), stopped using this parameter for the `"stream"` type. Previously, in the case of the `"stream"` type, it accepted a single-element list containing the ID of the channel. A new parameter, `stream_id`, is now used for this. Note that the `"channel"` type did not exist at this feature level. Support for typing notifications for channel' messages is new in Zulip 4.0 (feature level 58). Previously, typing notifications were only for direct messages. Before Zulip 2.0.0, this parameter accepted only a JSON-encoded list of email addresses. Support for the email address-based format was removed in Zulip 3.0 (feature level 11).
`stream_id`	Integer	No	ID of the channel in which the message is being typed. Required for the `"stream"` or `"channel"` type. Ignored in the case of `"direct"` type. Changes: New in Zulip 8.0 (feature level 215). Previously, a single-element list containing the ID of the channel was passed in `to` parameter.
`topic`	String	No	Topic to which message is being typed. Required for the `"stream"` or `"channel"` type. Ignored in the case of `"direct"` type. 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. Changes: Before Zulip 10.0 (feature level 372), `"(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 4.0 (feature level 58). Previously, typing notifications were only for direct messages.
`op`	String	Yes	Whether the user has started (`"start"`) or stopped (`"stop"`) typing. Valid values: `"stop"` `"start"`
`type`	String	No	Type of the message being composed. Changes: In Zulip 9.0 (feature level 248), `"channel"` was added as an additional value for this parameter to indicate a channel message is being composed. In Zulip 8.0 (feature level 215), stopped supporting `"private"` as a valid value for this parameter. In Zulip 7.0 (feature level 174), `"direct"` was added as the preferred way to indicate a direct message is being composed, becoming the default value for this parameter and deprecating the original `"private"`. New in Zulip 4.0 (feature level 58). Previously, typing notifications were only for direct messages. Valid values: `"channel"` `"stream"` `"direct"` Default value: "direct"

How to start integrating

Add HTTP Task to your workflow definition.
Search for the API you want to integrate with and click on the name.
- This loads the API reference documentation and prepares the Http request settings.
Click Test request to test run your request to the API and see the API's response.