Register an event queue

POST https://chat.convergenceservices.in/api/v1/register

This powerful endpoint can be used to register a uKnowva Messenger "event queue" (subscribed to certain types of "events", or updates to the messages and other uKnowva Messenger data the current user has access to), as well as to fetch the current state of that data.

(register also powers the call_on_each_event Python API, and is intended primarily for complex applications for which the more convenient call_on_each_event API is insufficient).

This endpoint returns a queue_id and a last_event_id; these can be used in subsequent calls to the "events" endpoint to request events from the uKnowva Messenger server using long-polling.

The server will queue events for up to 10 minutes of inactivity. After 10 minutes, your event queue will be garbage-collected. The server will send heartbeat events every minute, which makes it easy to implement a robust client that does not miss events unless the client loses network connectivity with the uKnowva Messenger server for 10 minutes or longer.

Once the server garbage-collects your event queue, the server will return an error with a code of BAD_EVENT_QUEUE_ID if you try to fetch events from the event queue. Your software will need to handle that error condition by re-initializing itself (e.g. this is what triggers your browser reloading the uKnowva Messenger webapp when your laptop comes back online after being offline for more than 10 minutes).

When prototyping with this API, we recommend first calling register with no event_types argument to see all the available data from all supported event types. Before using your client in production, you should set appropriate event_types and fetch_event_types filters so that your client only requests the data it needs. A few minutes doing this often saves 90% of the total bandwidth and other resources consumed by a client using this API.

See the events system developer documentation if you need deeper details about how the uKnowva Messenger event queue system works, avoids clients needing to worry about large classes of potentially messy races, etc.

Usage examples

Python
JavaScript
curl

#!/usr/bin/env python3

import zulip

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

# Register the queue
result = client.register(
    event_types=['message', 'realm_emoji']
)
print(result)

More examples and documentation can be found here.

const zulip = require('zulip-js');

// Pass the path to your zuliprc file here.
const config = {
    zuliprc: 'zuliprc',
};

zulip(config).then((client) => {
    // Register a queue
    const params = {
        event_types: ['message']
    };
    client.queues.register(params).then(console.log);
});

curl https://chat.convergenceservices.in/api/v1/register \
    -u BOT_EMAIL_ADDRESS:BOT_API_KEY
    -d 'event_types=["message"]'

Arguments

Argument	Example	Required	Description
`apply_markdown`	`true`	No	Set to `true` if you would like the content to be rendered in HTML format (otherwise the API will return the raw text that the user entered) Defaults to `false`.
`client_gravatar`	`true`	No	The `client_gravatar` field is set to `true` if clients can compute their own gravatars. Defaults to `false`.
`event_types`	`"event_types=['message']"`	No	A JSON-encoded array indicating which types of events you're interested in. Values that you might find useful include: * message (messages), * subscription (changes in your subscriptions), * realm_user (changes in the list of users in your realm) If you do not specify this argument, you will receive all events, and have to filter out the events not relevant to your client in your client code. For most applications, one is only interested in messages, so one specifies: `event_types=['message']`
`all_public_streams`	`true`	No	Set to `True` if you would like to receive events that occur within all public streams. Defaults to `false`.
`include_subscribers`	`true`	No	Set to `True` if you would like to receive events that include the subscribers for each stream. Defaults to `false`.
`fetch_event_types`	`"event_types=['message']"`	No	Same as the `event_types` argument except that the values in `fetch_event_types` are used to fetch initial data. If `fetch_event_types` is not provided, `event_types` is used and if `event_types` is not provided, this argument defaults to `None`.
`narrow`	`"narrow=['stream', 'Denmark']"`	No	A JSON-encoded array of length 2 indicating the narrow for which you'd like to receive events for. For instance, to receive events for the stream `Denmark`, you would specify `narrow=['stream', 'Denmark']`. Another example is `narrow=['is', 'private']` for private messages. Defaults to `"narrow=[]"`.

Response

Return values

queue_id: The ID of the queue that has been allocated for your client.
last_event_id: The initial value of last_event_id to pass to GET /api/v1/events.

Example response

A typical successful JSON response may look like:

{
    "last_event_id": -1,
    "msg": "",
    "queue_id": "1517975029:0",
    "realm_emoji": {
        "1": {
            "author": {
                "email": "iago@zulip.com",
                "full_name": "Iago",
                "id": 5
            },
            "deactivated": false,
            "id": "1",
            "name": "green_tick",
            "source_url": "/user_avatars/1/emoji/images/1.png"
        }
    },
    "result": "success"
}

Home

Integrations

Interactive bots (beta)

REST API

Messages

Streams

Users

Server & organizations

Real-time events