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:
userId
that 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.
In @liveblocks/node
, we made the field userId
in the authorize
option
mandatory. This userId
is used to track MAU associated with a Liveblocks
account. Each userId
will count as one MAU. To make sure you begin to track
MAU as intended, first update @liveblocks/node
.
Then, update the authorize
function to include the userId
field.
When calling the authorize
endpoint directly with a secret key, the userId
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.
Inside the createClient
function, you will use your public key instead of a
private key.
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 authorize
from @liveblocks/node
.
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.