Edit a scheduled message
PATCH https://cse1010sp20.zulip.engr.uconn.edu/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://cse1010sp20.zulip.engr.uconn.edu/api/v1/scheduled_messages/2 \
-u BOT_EMAIL_ADDRESS:BOT_API_KEY \
--data-urlencode type=stream \
--data-urlencode to=8 \
--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" for a stream 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", then the topic parameter is also required.
In Zulip 7.0 (feature level 174), "direct" was added as the
preferred way to indicate the type of a direct message, deprecating
the original "private". While "private" is supported for
scheduling direct messages, clients are encouraged to use to the
modern convention because support for "private" may eventually
be removed.
Must be one of: "direct", "stream", "private".
to integer | (integer)[] optional
Example: 8
The scheduled message's tentative target audience.
For stream messages, the integer ID of the stream.
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". 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 stream message is scheduled
to be sent to a stream that does not exist:
{
"code": "STREAM_DOES_NOT_EXIST",
"msg": "Stream 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"
}