Edit a scheduled message

PATCH https://wassail.chat/api/v1/scheduled_messages/{scheduled_message_id}

Changes: New in Zulip 7.0 (feature level 184).

Usage examples

curl

curl -sSX PATCH https://wassail.chat/api/v1/scheduled_messages/2 \
    -u BOT_EMAIL_ADDRESS:BOT_API_KEY \
    --data-urlencode type=stream \
    --data-urlencode to=11 \
    --data-urlencode content=Hello \
    --data-urlencode topic=Castle \
    --data-urlencode scheduled_delivery_timestamp=3165826990

Parameters

scheduled_message_id integer required in path

Example: 2

The ID of the scheduled message to update.

This is different from the unique ID that the message would have after being sent.

type string optional

Example: "stream"

The type of scheduled message to be sent. "direct" for a direct message and "stream" or "channel" for a channel message.

When updating the type of the scheduled message, the to parameter is required. And, if updating the type of the scheduled message to "stream"/"channel", then the topic parameter is also required.

Note that, while "private" is supported for scheduling direct messages, clients are encouraged to use to the modern convention of "direct" to indicate this message type, because support for "private" may eventually be removed.

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

Must be one of: "direct", "channel", "stream", "private".

to integer | (integer)[] optional

Example: 11

The scheduled message's tentative target audience.

For channel messages, the integer ID of the channel. For direct messages, a list containing integer user IDs.

Required when updating the type of the scheduled message.

content string optional

Example: "Hello"

The updated content of the scheduled message.

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

topic string optional

Example: "Castle"

The updated topic of the scheduled message.

Required when updating the type of the scheduled message to "stream" or "channel". Ignored when the existing or updated type of the scheduled message is "direct" (or "private").

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

scheduled_delivery_timestamp integer optional

Example: 3165826990

The UNIX timestamp for when the message will be sent, in UTC seconds.

Required when updating a scheduled message that the server has already tried and failed to send. This state is indicated with "failed": true in scheduled_messages objects; see response description at GET /scheduled_messages.

Response

Example response(s)

Changes: As of Zulip 7.0 (feature level 167), if any parameters sent in the request are not supported by this endpoint, a successful JSON response will include an ignored_parameters_unsupported array.

A typical successful JSON response may look like:

{
    "msg": "",
    "result": "success"
}

A typical failed JSON response for when a channel message is scheduled to be sent to a channel that does not exist:

{
    "code": "STREAM_DOES_NOT_EXIST",
    "msg": "Channel with ID '9' does not exist",
    "result": "error",
    "stream_id": 9
}

A typical failed JSON response for when a direct message is scheduled to be sent to a user that does not exist:

{
    "code": "BAD_REQUEST",
    "msg": "Invalid user ID 10",
    "result": "error"
}

A typical failed JSON response for when no scheduled message exists with the provided ID:

{
    "code": "BAD_REQUEST",
    "msg": "Scheduled message does not exist",
    "result": "error"
}

Zulip homepage

API documentation home

Integrations

Interactive bots (beta)

REST API

Messages

Scheduled messages

Drafts

Channels

Users

Invitations

Server & organizations

Real-time events

Specialty endpoints

Back to Zulip

Edit a scheduled message

Usage examples

Parameters

Response

Example response(s)