Fetch an API key (JWT)

POST https://your-org.chat.lgprk.ru/api/v1/jwt/fetch_api_key

Fetch a Zulip API key using a JSON Web Token (JWT) issued by an external application. The JWT is verified with the organization's configured JWT_AUTH_KEYS secret, and the email claim must identify an existing user in the organization.

The JWT payload must have the structure {"email": "<target user email>"}.

This endpoint is intended for server-to-server integrations: a separate application authenticates a user, signs a JWT, and then uses this endpoint to obtain that user's Zulip API key in order to make API requests on their behalf.

JWT authentication must be enabled for the organization via JWT_AUTH_KEYS in /etc/zulip/settings.py. See the JWT authentication docs for configuration details.

The token may be sent as a POST form field or as a query parameter.

Changes: New in Zulip 6.2 (feature level 160).

Usage examples

curl -sSX POST https://your-org.chat.lgprk.ru/api/v1/jwt/fetch_api_key \
    --data-urlencode token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6ImlhZ29AenVsaXAuY29tIn0.signature \
    --data-urlencode include_profile=false

Parameters

Response

Return values

• api_key: string

  The API key that can be used to authenticate as the requested user.

• email: string

  The email address of the user who owns the API key.

• user: object

  A dictionary containing basic data on a given Zulip user.

  Changes: Removed is_billing_admin field in Zulip 10.0 (feature level 363), as it was replaced by the can_manage_billing_group realm setting.

  • user_id: integer

    The unique ID of the user.

  • delivery_email: string | null

    The user's real email address. This value will be null if you cannot access user's real email address. For bot users, this field is always set to the real email of the bot, because bot users always have email_address_visibility set to everyone.

    Changes: Prior to Zulip 7.0 (feature level 163), this field was present only when email_address_visibility was restricted and you had access to the user's real email. As of this feature level, this field is always present, including the case when email_address_visibility is set to everyone (and therefore not restricted).

  • email: string

    The Zulip API email address of the user or bot.

    If you do not have permission to view the email address of the target user, this will be a fake email address that is usable for the Zulip API but nothing else.

  • full_name: string

    Full name of the user or bot, used for all display purposes.

  • date_joined: string

    The time the user account was created.

  • is_active: boolean

    A boolean specifying whether the user account has been deactivated.

  • is_owner: boolean

    A boolean specifying whether the user is an organization owner. If true, is_admin will also be true.

    Changes: New in Zulip 3.0 (feature level 8).

  • is_admin: boolean

    A boolean specifying whether the user is an organization administrator.

  • is_guest: boolean

    A boolean specifying whether the user is a guest user.

  • is_bot: boolean

    A boolean specifying whether the user is a bot or full account.

  • bot_type: integer | null

    An integer describing the type of bot:

    • null if the user isn't a bot.
    • 1 for a Generic bot.
    • 2 for an Incoming webhook bot.
    • 3 for an Outgoing webhook bot.
    • 4 for an Embedded bot.

  • bot_owner_id: integer | null

    If the user is a bot (i.e. is_bot is true), then bot_owner_id is the user ID of the bot's owner (usually, whoever created the bot).

    Will be null for legacy bots that do not have an owner.

    Changes: New in Zulip 3.0 (feature level 1). In previous versions, there was a bot_owner field containing the email address of the bot's owner.

  • role: integer

    Organization-level role of the user. Possible values are:

    • 100 = Organization owner
    • 200 = Organization administrator
    • 300 = Organization moderator
    • 400 = Member
    • 600 = Guest

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

  • timezone: string

    The IANA identifier of the user's profile time zone, which is used primarily to display the user's local time to other users.

  • avatar_url: string | null

    URL for the user's avatar.

    Will be null if the client_gravatar query parameter was set to true, the current user has access to this user's real email address, and this user's avatar is hosted by the Gravatar provider (i.e. this user has never uploaded an avatar).

    Changes: Before Zulip 7.0 (feature level 163), access to a user's real email address was a realm-level setting. As of this feature level, email_address_visibility is a user setting.

    In Zulip 3.0 (feature level 18), if the client has the user_avatar_url_field_optional capability, this will be missing at the server's sole discretion.

  • avatar_version: integer

    Version for the user's avatar. Used for cache-busting requests for the user's avatar. Clients generally shouldn't need to use this; most avatar URLs sent by Zulip will already end with ?v={avatar_version}.

  • profile_data: object

    Only present if is_bot is false; bots can't have custom profile fields.

    A dictionary containing custom profile field data for the user. Each entry maps the integer ID of a custom profile field in the organization to a dictionary containing the user's data for that field. Generally the data includes just a single value key; for those custom profile fields supporting Markdown, a rendered_value key will also be present.

    • {id}: object

      Object with data about what value the user filled in the custom profile field with that ID.

      • value: string

        User's personal value for this custom profile field.

      • rendered_value: string

        The value rendered in HTML. Will only be present for custom profile field types that support Markdown rendering.

        This user-generated HTML content should be rendered using the same CSS and client-side security protections as are used for message content.

        See Markdown message formatting for details on Zulip's HTML format.

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:

{
    "api_key": "gjA04ZYcqXKalvYMA8OeXSfzUOLrtbZv",
    "email": "iago@zulip.com",
    "msg": "",
    "result": "success"
}

An example JSON error response when JWT authentication is not configured for the organization:

{
    "code": "BAD_REQUEST",
    "msg": "JWT authentication is not enabled for this organization",
    "result": "error"
}

An example JSON error response when the request does not include a JWT:

{
    "code": "BAD_REQUEST",
    "msg": "No JSON web token passed in request",
    "result": "error"
}

An example JSON error response when the JWT is malformed or has an invalid signature:

{
    "code": "BAD_REQUEST",
    "msg": "Bad JSON web token",
    "result": "error"
}

An example JSON error response when the JWT payload does not contain an email claim:

{
    "code": "BAD_REQUEST",
    "msg": "No email specified in JSON web token claims",
    "result": "error"
}

An example JSON error response when the email in the JWT does not match an active user in the organization:

{
    "code": "AUTHENTICATION_FAILED",
    "msg": "Your username or password is incorrect",
    "result": "error"
}