Subscriptions

As PubNub allows you to have hundreds or even thousands of subscriptions, it's vital to understand how to manage them efficiently.

icon

Understanding the subscribe loop


Read on to understand what subscriptions and subscription sets are, and how to manage multiple channels with channel groups, wildcards, and Message Filters.

Receiving messages

To receive and handle incoming messages, signals, and events, you have to add an event listener first. If you're new to PubNub, make sure to check out how to set up your account as well.

Subscription types

The basic types of subscriptions are entity-scoped subscriptions and subscription sets. Within the PubNub SDKs, they are represented as Subscription and SubscriptionSet (although naming may vary between SDKs). For more information, refer to Entities.

Entity-enabled SDKs

Not all PubNub SDKs currently support entities. Refer to each SDK's API documentation for more information.

icon

How we did subscriptions in the past


Subscription typeWhen to useSample usageBenefits
Subscription
When you want to introduce more granularity and flexibility to the way you handle particular events.
If you want to handle the same message differently on two (or however many) channels, you can create a separate subscription for each channel and attach different event listeners.
  • Create multiple subscription objects that can be activated/deactivated without affecting others
  • Event handlers tied to specific subscriptions eliminate complex conditional logic
  • Multiple subscriptions are multiplexed over a single connection
SubscriptionSet
When you want to introduce common functionality to a number of events.
If you want to have a common logic for specific updates (for example, handling status updates), you can create a subscription set with all channels where user's presence is to be monitored and attach a single event listener.
  • Manage multiple channels as a group without tracking global state
  • Apply the same event handling logic across multiple channels
  • Each component can manage its own subscription set

Both Subscription and SubscriptionSet objects have intuitive interfaces for subscription-related operations (like switching between the active and inactive states) and working with listeners. On top of that, you can create subscription sets from existing entity-scoped subscriptions if you decide you need to handle a bunch of subscriptions similarly.

icon

Sample usage


Subscription options

You can parametrize the real-time data stream created using the Subscription and SubscriptionSet objects by specifying optional subscription options. Those options are shared across SDKs although you have to consider programming language differences in naming conventions.

Available options include:

Subscription optionDescription
filter
Allows you to specify arbitrary filtering for events coming through the subscription.
receivePresenceEvents
Allows you to decide whether to receive presence updates.

For more information on how to use the subscription options in each SDK, refer to each SDK's Subscribe section of the API documentation, for example, in JavaScript.

Create subscriptions

Each SDK has dedicated methods to create subscriptions and subscription sets. For more information on managing subscriptions, refer to each SDK's Subscribe section of the API documentation, for example, JavaScript.

Receiving events on subscriptions

You can assign functions directly to event-specific properties on the subscription object. This approach provides a clean, straightforward way to handle specific events.

const channelSubscription = pubnub.channel('channel_name').subscription();
channelSubscription.subscribe();

// Handle messages
channelSubscription.onMessage = function(message) {
console.log('Received message:', message);
};

// Handle presence events
channelSubscription.onPresence = function(presenceEvent) {
console.log('Presence event:', presenceEvent);
};

// Other handlers are available for signals, objects, files, and message actions

This method allows for clear, direct assignment of handlers to specific event types and is particularly useful when you want to add or change handlers dynamically.

For more information on how to use the on[Event] syntax, refer to each SDK's API documentation, for example, JavaScript.

Both approaches achieve the same result, so you can choose the style that best fits your application's architecture and your team's preferences. The specific syntax may vary slightly between SDKs, so refer to your SDK's documentation for details.

Subscribe to channels

Once the listener object is established, the client can request to subscribe to individual channels. Subscribing to channels initiates a connection with the PubNub Platform which triggers a connection status event. This connection is kept open for the duration that the client stays subscribed to at least one channel. Any user subscribing to a channel receives messages in under 30ms, regardless of location.

Default subscribe timeout

There is a default timeout of 310 seconds (~5 min) for all requests related to subscribed channels that the client sends to the server. You can reduce this limit in your client configuration by specifying a different value for the subscribeTimeout parameter.

The client can subscribe to several channels simultaneously through a single open connection. Typically, you subscribe to channels on app load. As the user navigates through your app, your app can remain subscribed to all the channels so it continues to receive messages on all of them. Alternatively, you can implement your app in a way that it subscribes and unsubscribes from channels as the user navigates through the app.

Configuration

If you want a single client to subscribe to multiple channels, you must have the Stream Controller feature enabled on your app's keyset in the Admin Portal to use the following subscription options:

  • Channel Multiplexing — subscribing to multiple channels in a single API call
  • Wildcard Subscriptions — subscribing to groups of channels that share a common naming pattern, like news.*
  • Channel Groups — creating named groups of channels and then subscribing to the group as a whole

Contrary to other features that you must specifically enable, Stream Controller is active by default on all new keysets.

Stream Controller in Admin Portal

OptionDescription
Enable Wildcard Subscribe
An option that lets you subscribe to groups of channels with a shared naming pattern, like *.chat.*
Channel group limit
The maximum number of channels you can add to channel groups. The default limit of 1,000 channels applies to all new keysets and can be modified if you have a paid account — you can then either lower the limit or increase it up to 2,000 channels.

Signal channel subscribe

To receive Signals, you don't need a different subscription to the channel, but you do need a separate signal event listener as mentioned in the Adding a Listener section.

Channel multiplexing

Subscribing to multiple channels from a single client is called multiplexing. You can subscribe to one or more channels by creating many individual subscription objects or subscription sets. You can also create individual subscriptions and create a subscription set from them when their number increases.

Multiplexing allows each client to subscribe to a combination of channels of their choosing and change that selection at any time.

Multiplexing is designed for a relatively small number of channels. While there is no hard limit, PubNub strongly recommends multiplexing between 10 and 50 channels for any subscribe, and possibly fewer if you are deploying a larger application. For bigger channel subscribe groupings, you should consider using channel groups.

Channel ID length impact

The longer the channel ID, the bigger the combined HTTP payload size. Channels with longer IDs increase the size of the multiplex request which may exceed the URI length limit of 32 KiB.

You can subscribe to one or more channels in a single request or you can spread those requests out in your application's flow. For example, a client might subscribe to chats.room1 now and then later subscribe to chats.room2. Doing so will simply add chats.room2 to the current list of channels that have already been subscribed as if you subscribed to them at the same time.

For example, below is how you would subscribe to a channel chats.room1 when the user of your app enter their first chat room.

const channel = pubnub.channel('chats.room1');
channel.subscription().subscribe();

The user continues to use your application, and then decides to enter another chat room, chats.room2.

// create a subscription from a channel entity
const channel = pubnub.channel('chats.room1')
const subscription1 = channel.subscription({ receivePresenceEvents: true });

// create a subscription from a channel entity
const channelGroup = pubnub.channel('chats.room2')
const subscription2 = channel.subscription();

const subscriptionSet = subscription1.addSubscription(subscription2);
subscriptionSet.subscribe();

The result is that the user is now subscribed to both chat room channels.

You can also leverage Channel Groups and Wildcard Subscribe. Below you'll be briefly introduced to these two alternative subscription management features.

Enable Stream Controller

Multiplexing is available by default, regardless of your Admin Portal configuration. However, to use the Wildcard Subscribe and Channel Groups features, the Stream Controller add-on must be enabled on your keyset in the Admin Portal.

Channel groups

You can think of a channel group like a pointer to a list of channels on your server. If your application requires listening to large numbers of channels at once, channel groups allow you to send a single call which may subscribe to up to 100 channels. By default, each individual client can subscribe to a maximum of 10 channel groups for a total of up to 1,000 channels.

Modify limits for channels in channel groups

The default limit of 1,000 channels in channel groups per keyset applies to all new keysets created in the Admin Portal. If you're on a paid account, you can modify that limit for your app in the Admin Portal by changing the value for the Channel group limit on your keyset configuration under the Stream Controller section. You can either lower the default limit or increase it up to 2,000 channels.

Subscribe vs. publish to channel groups

Channel groups can also be thought of as a subscribe group, because you can only subscribe to a channel group and you can't publish to a channel group. There are definite advantages to using channel groups when your clients must subscribe to a lot of channels. Your server adds channels to a channel group and clients can subscribe to all those channels contained in the channel group simply by subscribing to that channel group.

Your clients may not need to listen to that many channels, but channel groups make it possible for your server to manage the channels that the client is subscribed to by adding and removing channels on behalf of the clients.

To use a channel group, instead of multiplexing, there is just one additional step - add channels to a channel group. This also creates the channel group if it doesn't already exist. This should be performed by your server for security and ease of management.

pubnub.channelGroups.addChannels({
channels: ["chats.room1", "chats.room2", "alerts.system"]
channelGroup: "cg_user123"
},
function(status) {
console.log(status);
}
);

The client subscribes to the channel group.

const channelGroup = pubnub.channelGroup('cg_user123');
channelGroup.subscribe();

When messages are published to any of the channels in this channel group, it will be received in the message handler of the client's listener. The channel group subscribes can also be enabled with withPresence parameter to start receiving presence events for all the channels in the Channel Group.

Subscription with Presence

To receive Presence events, you subscribe with Presence and have Presence enabled on your keyset. Make sure you configure Presence to track Presence-related events for all or selected channels (through Presence Management rules).

Be aware of whether this is necessary for your use case or not. You can separate channels into two channels groups: cg_presence_user123 (channels with presence tracking) and cg_user123 (channels without presence tracking). This can all be done on the client app. but when we talk about channel access security (Access Manager), it will be clear why clients should never be able to add/remove channels to/from a channel group.

Additionally, with Channel Groups your server can force a client to unsubscribe from a particular channel just by removing that channel from the channel group that the client is subscribed to.

Channel group names

Channel groups can be shared just like channels. For example, you may want to create a channel group called cg_sports. Multiple clients can subscribe to this shared channel group and your server can add new channels related to sports and all the clients will automatically be subscribed to those new channels.

And there is no requirement to prefix the name with cg_. It's only a convention that makes it easy to recognize Channel Groups. Feel free to use a naming convention that works best for your requirements and design style.

Channel Group Names

Channel Group names have the same rules as Channel names with one exception: you can't use a period in the name. This means that wildcard features do not apply to Channel Groups.

Just because you're using Channel Groups does not mean you can't also subscribe to individual channels. Sometimes it may be convenient to subscribe to a particular channel directly while also subscribing to a separate Channel Group. You can specify channels and channel groups in the same subscribe call or make individual subscribe calls. And channel groups can be multiplexed, too.

Wildcard subscribe

Wildcard Subscribe channelName.* can be used to subscribe to a hierarchical list of channels. It's similar to Channel Group in that you can subscribe to lots of channels with a single name declaration. For example, you specify a wildcard channel pattern like sports.*, and your app will subscribe to all channel names that match that pattern: sports.cricket, sports.lacrosse. This list can be virtually infinite in number with some limitations described in the next section.

const channel = pubnub.channel("alerts.*");
channel.subscription().subscribe();

Wildcard subscribe rules

There are some limits to what you can do with the Wildcard Subscribe. Below is a quick summary of the rules:

  • You're limited to two dots (three levels). For example, you can subscribe to a.* or a.b.* but not a.b.c.*.
  • A wildcard pattern must always end with .*. In other words, the * can't be in the middle of the pattern (a.*.c, isn't valid).
  • Just like Channel Groups, you can not publish to a wildcard channel pattern.

Message filters

PubNub's subscribe filters enable sophisticated server-side message filtering, allowing you to receive only the messages that match specific criteria. Instead of receiving all messages and filtering them client-side, PubNub filters messages on the server before transmission, significantly reducing bandwidth and improving performance.

Key capabilities include:

  • Message payload filtering - Filter based on any field in the message content using data.* syntax
  • Metadata filtering - Filter based on metadata attached during publishing using meta.* syntax
  • Advanced operations - Support for pattern matching (LIKE, CONTAINS), arithmetic (modulo, comparisons), array/object access, and complex compound expressions
  • Real-time performance - Filters are applied server-side with minimal latency impact

Subscribe filters can access two main data sources:

  • data.fieldName - Any field within the published message payload
  • meta.fieldName - Any metadata field attached via the meta parameter during publishing
Publisher and channel filtering limitations

You cannot directly filter on publisher ID, channel names, or message types through envelope fields. To filter by these properties, you must include them in the message metadata during publishing.

Basic filter examples

// Message payload filtering
data.type == "alert" // Filter by message type
data.priority != "low" // Exclude low priority
data.user["role"] == "admin" // Filter by user role in payload

// Metadata filtering
meta.region == "San Francisco" // Geographic filtering
meta.level > 5 // Numeric thresholds
meta.category LIKE "news*" // Pattern matching

// Combined filtering
(meta.priority == "high") && (data.text CONTAINS "urgent")

Setting filter expressions

// Initialize PubNub
var pubnub = new PubNub({
publishKey: "myPublishKey",
subscribeKey: "mySubscribeKey",
userId: "myUserId"
});

// Set filter expression for metadata filtering
pubnub.setFilterExpression('meta.priority == "high"');

// Set filter expression for payload filtering
pubnub.setFilterExpression('data.type == "alert"');

// Set complex filter expression
pubnub.setFilterExpression('(meta.priority == "high") && (data.user["role"] == "admin")');

Filterable message properties

Subscribe filters can access the following message components:

SupportedPropertyFilter accessExamplesNotes
Yes
Message payload
data.*
data.text, data.type, data.user["role"], data.tags[0]
Any field within the published message content
Yes
Message metadata
meta.*
meta.priority, meta.level, meta.user["role"], meta.flags[0]
Metadata attached via the meta parameter
No
Publisher user ID
n/a
n/a
Include in metadata as meta.publisher if needed
No
Channel name
n/a
n/a
Include in metadata as meta.channel if needed
No
Timetoken
n/a
n/a
Not accessible to filter expressions
No
Message type (envelope field)
n/a
n/a
Include in payload as data.type or in metadata as meta.type

Advanced access patterns

These examples show common ways to access arrays and objects, apply arithmetic, match patterns, and combine conditions in subscribe filter expressions.

  • Array access: meta.tags[0] == "urgent", data.recipients[1] LIKE "*@domain.com"
  • Object access: meta.user["role"] == "admin", data.config["enabled"] == "true"
  • Arithmetic: meta.userId % 10 == 0, data.score > (meta.threshold * 1.1)
  • Pattern matching: meta.category LIKE "news*", data.text CONTAINS "urgent"
  • Compound logic: (meta.priority == "high" || meta.priority == "critical") && data.type == "alert"

For comprehensive documentation, syntax reference, and advanced examples, see Subscribe Filter Details.

Common use cases

Use these filters to route content, run analytics, and handle IoT data.

Content-based routing
// High-priority alerts from specific regions
(meta.priority == "high" || meta.priority == "critical") && meta.region == "San Francisco"

// User role-based messaging
data.user["role"] == "admin" && data.action != "routine"
Real-time analytics filtering
// Sample 10% of events for analytics
meta.eventId % 10 == 0 && data.category == "conversion"

// Error monitoring for production systems
data.severity == "error" && meta.environment == "production"
IoT data stream filtering
// Temperature alerts only
data.sensor["type"] == "temperature" && data.value > meta.thresholds["critical"]

// Device health monitoring
meta.device["status"] != "maintenance" && data.battery < 20

Advanced filter capabilities

Use these patterns to access arrays and objects, perform arithmetic, and handle booleans.

Array and object access
meta.permissions[0] == "admin"                // Array element access
meta.user["department"] == "engineering" // Object property access
data.recipients[1] LIKE "*@company.com" // Pattern matching on arrays
meta.config["alerts"]["email"] == "enabled" // Single-level nesting only
Arithmetic operations
meta.userId % 100 == 0                        // Modulo sampling (1%)
data.score > (meta.baseline + 10) // Calculated thresholds
meta.attempts < (meta.maxRetries - 1) // Range validation
Boolean value handling
meta.enabled == "true"                        // Boolean as string (recommended)
meta.active != "false" // Boolean inequality check
meta.flag == 1 // Numeric boolean (1=true, 0=false)
Boolean literals not supported

Use string comparison (meta.field == "true") instead of boolean literals (meta.field == true). JSON boolean values are stored as strings and must be compared as such.

For complete syntax reference, advanced examples, performance guidelines, and troubleshooting information, see the comprehensive Subscribe Filter Details documentation.

Unsubscribe from channels

Unsubscribe from a channel to stop receiving its messages. You can use this method to unsubscribe from one or more channels.

// create a subscription from a channel entity
const channel = pubnub.channel('channel_1')
const subscription1 = channel.subscription({ receivePresenceEvents: true });

// create a subscription set with multiple channels
const subscriptionSet1 = pubnub.subscriptionSet({ channels: ['ch1', 'ch2'] });

subscription1.subscribe();
subscriptionSet1.subscribe();

subscription1.unsubscribe();
subscriptionSet1.unsubscribe();

Unsubscribe from all channels

Use this method to unsubscribe from all channels.

// create a subscription set with multiple channels
const subscriptionSet1 = pubnub.subscriptionSet({ channels: ['ch1', 'ch2'] });
subscriptionSet1.subscribe();

// create a subscription from a channel entity
const channelGroup = pubnub.channelGroup('channelGroup_1')
const subscription1 = channelGroup.subscription({ receivePresenceEvents: true });
subscription1.subscribe();

pubnub.unsubscribeAll();

Deprecation of previous subscription APIs

As PubNub introduces the new entity-based subscription architecture across its SDKs, the previous global subscription APIs (such as pubnub.subscribe() and pubnub.unsubscribe()) are being marked as deprecated. However, to ensure a smooth transition for developers, each SDK supports a long end-of-life (EOL) period.

The deprecation timeline varies by SDK. For example, in the JavaScript SDK, the "old" pubnub.subscribe() and pubnub.unsubscribe() methods have been marked as deprecated but will continue to function for the documented EOL period.

For specific information about the deprecation schedule for your SDK, please refer to the documented EOL period in your SDK's documentation, typically found toward the bottom of the SDK feature list.

Status events

When channels are subscribed, connections are disconnected, reconnected or when connection errors are encountered, status events are generated and clients can receive those events in the listener's status listener.

Listener

The status listener is the only listener that you add to the pubnub object, and not to a particular subscription or a subscription set.

Most SDKs provide an operation and category as part of a status event. The supported categories may vary with each language and platform, and some SDKs may have a more robust architecture than others. The differences will be noted as necessary.

Handle status events

The event listeners are briefly mentioned in Receive Messages. Compared to other event types, status events are more focused on connection status and subscribe request errors.

Because the browser can detect when the connection is lost and restored, the JavaScript SDK (when running in a browser) has two additional events that allow you to explicitly handle those scenarios: PNNetworkDownCategory and PNNetworkUpCategory. Other environments do not support this real-time network status behavior.

The following data can be extracted from a JavaScript SDK status event.

// add a status listener
pubnub.addListener({
status: (s) => {
console.log('Status', s.category),
}
});

// available data:
// var affectedChannelGroups = event.affectedChannelGroups;
// var affectedChannels = event.affectedChannels;
// var category = event.category;
// var operation = event.operation;
// var lastTimetoken = event.lastTimetoken;
// var currentTimetoken = event.currentTimetoken;
// var subscribedChannels = event.subscribedChannels;

For more details on handling Status Events, visit the JavaScript SDK Status Events documentation page.

Last updated on