POST /mobile_push/register
Register a device to receive end-to-end encrypted mobile push notifications, or update such a registration.
To perform an initial registration, clients must provide both the
push key fields (push_key and push_key_id) and the token fields
(token_kind, token_id, bouncer_public_key, and encrypted_push_registration).
Once registered, clients should use this endpoint to rotate push_key or
FCM/APNs provided token:
- Rotate push key: Provide only the push key fields.
- Rotate token: Provide only the token fields.
On a successful registration, the server automatically removes any legacy push device registration with a matching token for the user. For self-hosted servers, if removing the legacy registration from the push notification bouncer fails (e.g., due to a network error), legacy notifications to that token will continue until all of the user's legacy registrations have been removed from the local server, at which point the server will stop sending legacy notification requests to the bouncer entirely.
Changes: In Zulip 12.0 (feature level 483), the server began automatically removing legacy registrations with a matching token on successful E2EE registration.
In Zulip 12.0 (feature level 468), the endpoint was significantly
redesigned to support rotation of push_key and token provided by FCM/APNs.
New in Zulip 11.0 (feature level 406).
Servers
- https://{subdomain}.zulipchat.com/api/v1
- {server}/api/v1
- https://chat.zulip.org/api/v1
Request headers
| Name | Type | Required | Description |
|---|---|---|---|
Content-Type |
String | Yes |
The media type of the request body.
Default value: "application/x-www-form-urlencoded" |
Request body fields
| Name | Type | Required | Description |
|---|---|---|---|
push_key_id |
Integer | No |
A random unsigned 32-bit integer generated by the client as an identifier
for |
token_id |
String | No |
Identifier for the FCM/APNs provided token to the device, produced by taking the first 8 bytes of the SHA-256 hash of the token, then encoding those bytes using standard Base64 encoding as defined in RFC 4648. |
token_kind |
String | No |
Whether the token was generated by FCM or APNs. Valid values:
|
bouncer_public_key |
String | No |
Which of the bouncer's public keys the client used to encrypt the
When the bouncer rotates the key, a new asymmetric key pair is created, and the new public key is baked into a new client release. Because the bouncer routinely rotates key, this field clarifies which public key the client is using. The public key is encoded using standard Base64 encoding as defined in RFC 4648. |
device_id |
Integer | Yes |
The ID of the device to configure for push notifications. See |
encrypted_push_registration |
String | No |
Ciphertext generated by encrypting a The |
push_key |
String | No |
Key that the client would like the server to use to encrypt notifications, encoded with Base64. The key is a byte sequence beginning with a single byte that encodes which cryptosystem to use, followed by the key to use for that cryptosystem. This byte sequence is encoded using standard Base64 encoding as defined in RFC 4648. The client should avoid sharing the key anywhere else: in particular it should generate a fresh key for each server, and to the extent possible keep the key out of any backups of the client's data. Supported cryptosystems are:
Changes: New in Zulip 12.0 (feature level 432). This replaced the
|
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.