With the release of Liveblocks 1.0, we included new pricing plans that are based
on Monthly Active Users (MAU). This guide will help you understand how to use
the new pricing plans by providing guidance on the migration to Liveblocks 1.0
and how to include a
userId when generating a token with the secret API key.
In versions before 1.0 we used the number of connections to determine pricing segments. We counted each time a user connected to a Liveblocks room from a physical device as a connection. We introduced pricing based on Monthly Active Users (MAU) to reflect the value that Liveblocks offers to our customers. MAU makes pricing more predictable for our users by associating connections to users.
A monthly active user can be defined as:
userIdthat connects to a Liveblocks room at least once a month (if using authorization with a secret API key)
It doesn’t matter how many rooms a user connects to, or how frequently Liveblocks APIs are used—one user is one MAU.
@liveblocks/node, we made the field
userId in the
userId is used to track MAU associated with a Liveblocks
userId will count as one MAU. To make sure you begin to track
MAU as intended, first update
Then, update the
authorize function to include the
When calling the
authorize endpoint directly with a secret key, the
is not required. However, should still include the
userId in the request body
to take advantage of MAU pricing logic. Set the
Authorization: Bearer header
to your secret key, then POST to the following endpoint:
Set the following request body:
To learn more about authorization and authentication in your Liveblocks application, check out our Authentication guide.
To take advantage of Liveblocks 1.0 pricing with the public API key authorization, you must update your Liveblocks packages to 1.0. We will count each connection as one MAU if you do not update your packages to 1.0. Once the packages are updated, a cookie will be set on the client to track when a new user connects to a room. This cookie will track MAU associated with a Liveblocks account and expire after 30 days.
createClient function, you will use your public key instead of a
To illustrate how counting MAU works without a
userId, consider the following:
If you have one user who connects to a Liveblocks room that does not enforce authorization, you will be billed for one MAU. That same person can reaccess a room the next day, and MAU would not increase. The cookie will expire at the end of the 30-day billing cycle, and the user will be counted as a new MAU. Liveblocks will count that anonymous user as two MAU if packages are not updated.
While working in development mode, you will not be billed for MAU. However, you
will still need to include a
userId in the
authorize option if you use it.
We are currently working on updating our dashboard to reflect the number of MAU
for development use.
If you connect to rooms and call the Liveblocks API during any automated testing,
you may want to provide a static
userId to avoid hitting limits.
For example, you could do this by setting an environment variable and checking
the process when you call
To update to Liveblocks 1.0, you will need to update your Liveblocks packages:
You will then pick one of the two methods outlined above for tracking MAU: authorization or public key. After completing these steps to take advantage of the new pricing model, you should review the Liveblocks 1.0 upgrade guide for additional details on migrating to Liveblocks 1.0.