Edit a scheduled message
PATCH https://lada.co.toya.net.pl/api/v1/scheduled_messages/{scheduled_message_id}
Edit an existing scheduled message.
Changes: New in Zulip 7.0 (feature level 184).
Usage examples
curl -sSX PATCH https://lada.co.toya.net.pl/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"
}