GET /users/{email}

Fetch details for a single user in the organization given a Zulip API email address.

You can also fetch details on all users in the organization or by user ID.

Fetching by user ID is generally recommended when possible, as a user might change their email address or change their email address visibility, either of which could change the client's ability to look them up by that email address.

Changes: In Zulip 12.0 (feature level 437), fixed a bug dating to feature level 232, which caused guest users to receive fake backwards-compatibility users in the format intended for clients using POST /register without the user_list_incomplete client capability.

Starting with Zulip 10.0 (feature level 302), the real email address can be used in the email parameter and will fetch the target user's data if and only if the target's email visibility setting permits the requester to see the email address. The dummy email addresses of the form user{id}@{realm.host} still work, and will now work for all users, via identifying them by the embedded user ID.

New in Zulip Server 4.0 (feature level 39).

Servers

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

Path parameters

Name Type Required Description

Name	Type	Required	Description
`email`	String	Yes	The email address of the user to fetch. Two forms are supported: The real email address of the user (`delivery_email`). The lookup will succeed if and only if the user exists and their email address visibility setting permits the client to see the email address. The dummy Zulip API email address of the form `user{user_id}@{realm_host}`. This is identical to simply getting user by ID. If the server or realm change domains, the dummy email address used has to be adjustment to match the new realm domain. This is legacy behavior for backwards-compatibility, and will be removed in a future release. Changes: Starting with Zulip 10.0 (feature level 302), lookups by real email address match the semantics of the target's email visibility setting and dummy email addresses work for all users, independently of their email visibility setting. Previously, lookups were done only using the Zulip API email addresses.

email

String

Yes

The email address of the user to fetch. Two forms are supported:

The real email address of the user (delivery_email). The lookup will succeed if and only if the user exists and their email address visibility setting permits the client to see the email address.
The dummy Zulip API email address of the form user{user_id}@{realm_host}. This is identical to simply getting user by ID. If the server or realm change domains, the dummy email address used has to be adjustment to match the new realm domain. This is legacy behavior for backwards-compatibility, and will be removed in a future release.

Changes: Starting with Zulip 10.0 (feature level 302), lookups by real email address match the semantics of the target's email visibility setting and dummy email addresses work for all users, independently of their email visibility setting.

Previously, lookups were done only using the Zulip API email addresses.

Query parameters

Name Type Required Description

Name	Type	Required	Description
`include_custom_profile_fields`	Boolean	No	Whether the client wants custom profile field data to be included in the response. Changes: New in Zulip 2.1.0. Previous versions do not offer these data via the API. Default value: false
`client_gravatar`	Boolean	No	Whether the client supports computing gravatars URLs. If enabled, `avatar_url` will be included in the response only if there is a Zulip avatar, and will be `null` for users who are using gravatar as their avatar. This option significantly reduces the compressed size of user data, since gravatar URLs are long, random strings and thus do not compress well. The `client_gravatar` field is set to `true` if clients can compute their own gravatars. Changes: The default value of this parameter was `false` prior to Zulip 5.0 (feature level 92). Default value: true

include_custom_profile_fields

Boolean

Whether the client wants custom profile field data to be included in the response.

Changes: New in Zulip 2.1.0. Previous versions do not offer these data via the API.

Default value: false

client_gravatar

Boolean

Whether the client supports computing gravatars URLs. If enabled, avatar_url will be included in the response only if there is a Zulip avatar, and will be null for users who are using gravatar as their avatar. This option significantly reduces the compressed size of user data, since gravatar URLs are long, random strings and thus do not compress well. The client_gravatar field is set to true if clients can compute their own gravatars.

Changes: The default value of this parameter was false prior to Zulip 5.0 (feature level 92).

Default value: true

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.