Mute a user

POST https://chat2.ifi.lmu.de/api/v1/users/me/muted_users/{muted_user_id}

Mute a user from the perspective of the requesting user. Messages sent by muted users will be automatically marked as read and hidden for the user who muted them.

Muted users should be implemented by clients as follows:

• The server will immediately mark all messages sent by the muted user as read. This will automatically clear any existing mobile push notifications related to the muted user.
• The server will mark any new messages sent by the muted user as read for the requesting user's account, which prevents all email and mobile push notifications.
• Clients should exclude muted users from presence lists or other UI for viewing or composing one-on-one direct messages. One-on-one direct messages sent by muted users should be hidden everywhere in the Zulip UI.
• Channel messages and group direct messages sent by the muted user should avoid displaying the content and name/avatar, but should display that N messages by a muted user were hidden (so that it is possible to interpret the messages by other users who are talking with the muted user).
• Group direct message conversations including the muted user should display muted users as "Muted user", rather than showing their name, in lists of such conversations, along with using a blank grey avatar where avatars are displayed.
• Administrative/settings UI elements for showing "All users that exist on this channel or realm", e.g. for organization administration or showing channel subscribers, should display the user's name as normal.

Changes: New in Zulip 4.0 (feature level 48).

Usage examples

#!/usr/bin/env python3

import zulip

# Pass the path to your zuliprc file here.
client = zulip.Client(config_file="~/zuliprc")

# Mute a user, given the user's ID.
result = client.call_endpoint(url=f"/users/me/muted_users/{muted_user_id}", method="POST")
print(result)

curl -sSX POST https://chat2.ifi.lmu.de/api/v1/users/me/muted_users/10 \
    -u BOT_EMAIL_ADDRESS:BOT_API_KEY

Parameters

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"
}

An example JSON response for when the user ID is the current user's ID:

{
    "code": "BAD_REQUEST",
    "msg": "Cannot mute self",
    "result": "error"
}

An example JSON response for when the user is nonexistent or inaccessible:

{
    "code": "BAD_REQUEST",
    "msg": "No such user",
    "result": "error"
}

An example JSON response for when the user is already muted:

{
    "code": "BAD_REQUEST",
    "msg": "User already muted",
    "result": "error"
}