The Liveblocks API is organized around REST. Our API has predictable resource-oriented URLs, accepts form-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.
With the Liveblocks API, you can authenticate requests, list and update rooms, list users, and more.
To use the API endpoints, you need to add your secret key to the request’s authorization header. Except for the public authorization endpoint.
Returns a list of your rooms. The rooms are returned sorted by creation date, from newest to oldest. You can filter rooms by metadata, users accesses and groups accesses.
There is a pagination system where the next page URL is returned in the response as nextPage
.
You can also limit the number of rooms by query.
Filtering by metadata works by giving key values like metadata.color=red
. Of course you can combine multiple metadata clauses to refine the response like metadata.color=red&metadata.type=text
. Notice here the operator AND is applied between each clauses.
Filtering by groups or userId works by giving a list of groups like groupIds=marketing,GZo7tQ,product
or/and a userId like userId=user1
.
Notice here the operator OR is applied between each groupIds
and the userId
.
limit
optionalA limit on the number of rooms to be returned. The limit can range between 1 and 100, and defaults to 20.
startingAfter
optionalA cursor used for pagination. You get the value from the response of the previous page.
metadata.KEY
optionalA filter on metadata. Multiple metadata keys can be used to filter rooms.
userId
optionalA filter on users accesses.
groupIds
optionalA filter on groups accesses. Multiple groups can be used.
Success. Returns the list of rooms and the next page URL.
Create a new room. id
and defaultAccesses
are required.
defaultAccessess
could be []
or ["room:write"]
(private or public).metadata
could be key/value as string
or string[]
. metadata
supports maximum 50 entries. Key length has a limit of 40 characters maximum. Value length has a limit of 256 characters maximum. metadata
is optional field.usersAccesses
could be []
or ["room:write"]
for every records. usersAccesses
can contain 100 ids maximum. Id length has a limit of 40 characters. usersAccesses
is optional field.groupsAccesses
are optional fields.Success. Returns the created room.
Get a room by its ID.
roomId
requiredID of the room
Success. Returns the room.
Updates specific properties of a room. It's not necessary to provide the entire room's information.
Setting a property to null
means to delete this property. For example, if you want to remove access to a specific user without losing other users:
{ "usersAccesses": { "john": null } }
defaultAccessess
, metadata
, usersAccesses
, groupsAccesses
can be updated.
defaultAccessess
could be []
or ["room:write"]
(private or public).metadata
could be key/value as string
or string[]
. metadata
supports maximum 50 entries. Key length has a limit of 40 characters maximum. Value length has a limit of 256 characters maximum. metadata
is optional field.usersAccesses
could be []
or ["room:write"]
for every records. usersAccesses
can contain 100 ids maximum. Id length has a limit of 256 characters. usersAccesses
is optional field.groupsAccesses
could be []
or ["room:write"]
for every records. groupsAccesses
can contain 100 ids maximum. Id length has a limit of 256 characters. groupsAccesses
is optional field.roomId
requiredID of the room
Success. Returns the updated room.
Deletes a room. A deleted room is no longer accessible from the API or the dashboard and it cannot be restored.
roomId
requiredID of the room
Returns a list of users currently present in the requested room. For better performance, we recommand to call this endpoint every 10 seconds maximum. Duplicates can happen if a user is in the requested room with multiple browser tabs opened.
roomId
requiredID of the room
Success. Returns the list of active users for the specified room.
Returns a room storage as JSON.
Some implementation details:
Each Liveblocks data structure is represented by a JSON element having two properties:
"liveblocksType": "LiveObject" | "LiveList" | "LiveMap"
"data"
=> contains the nested data structures (children) and data.
The root is always a LiveObject
.
roomId
requiredID of the room
Success. Returns the room storage as JSON.
Initializes a room storage. The room must already exist and have an empty storage. Calling this endpoint will disconnect all users from the room if there are any.
The format of the request body is the same as what’s returned by the get storage endpoint.
For each Liveblocks data structure that you want to create, you need a JSON element having two properties:
"liveblocksType"
=> "LiveObject" | "LiveList" | "LiveMap"
"data"
=> contains the nested data structures (children) and data.The root’s type can only be LiveObject.
A utility function, toPlainLson
is included in @liveblocks/client
from 1.0.9
to help convert LiveObject
, LiveList
, and LiveMap
to the structure expected by the endpoint.
roomId
requiredID of the room
Success. The storage is initialized. Returns the room storage as JSON.
Deletes all of the room’s storage data. Calling this endpoint will disconnect all users from the room if there are any.
roomId
requiredID of the room
This endpoint lets your application server (= your backend) obtain a token that one of its clients (= your frontend) can use to enter a Liveblocks room. You use this endpoint to implement your own application’s custom authentication endpoint. When making this request, you’ll have to use your secret key.
You can pass the property userId
in the request's body. This can be whatever internal identifier you use for your user accounts as long as it uniquely identifies an account. Setting the userId
is optional if you want to use public rooms, but it is required to enter a private room (because permissions are assigned to specific user IDs). In case you want to use the group permission system, you can also declare which groupIds
this user belongs to.
The property userId is used by Liveblocks to calculate your account’s Monthly Active Users. One unique userId corresponds to one MAU. If you don’t pass a userId, we will create for you a new anonymous userId on each connection, but your MAUs will be higher.
Additionally, you can set custom metadata to the token, which will be publicly accessible by other clients through the user.info
property. This is useful for storing static data like avatar images or the user’s display name.
roomId
requiredID of the room
Success. Returns the JWT token.
This endpoint enables the broadcast of an event to a room without having to connect to it via the client
from @liveblocks/client
. It takes any valid JSON as a request body.
roomId
requiredID of the room
This endpoint works with the public key and can be used client side. That means you don't need to implement a dedicated authorization endpoint server side.
The generated JWT token works only with public room (defaultAccesses: ["room:write"]
).
roomId
requiredID of the room
Success. Returns the JWT token.
Creates a new schema which can be referenced later to enforce a room's storage data structure. The schema consists of a name (for referencing it), and a body, which specifies the exact allowed shape of data in the room. This body is a multi-line string written in the Liveblocks schema syntax.
Success. Creates the new schema and returns it as JSON.
This endpoint retrieves a schema by its id. The id is a combination of the schema name and version. For example, my-schema@1
.
id
requiredID of the schema
Success. Found the schema and returns it as JSON.
Updates the body for the schema. A schema can only be updated if it is not used by any room.
id
requiredID of the schema
Success. Updates the new schema and increments the version. The schema body
is returned as JSON.
This endpoint deletes a schema by its ID. The ID is a combination of the schema name and version. For example, my-schema@1
. A schema can only be deleted if it is not attached to a room.
id
requiredID of the schema
This endpoint retrieves the schema attached to a room.
roomId
requiredID of the room
Success. Found the schema attached to the room and returns it as JSON.
This endpoint attachs a schema to a room, and instantly enables runtime schema validation for the room. If the current contents of the room's storage do not match the schema, attaching will fail and the error message will give details on why the schema failed to attach.
roomId
requiredID of the room
Success. Found the schema attached to the room. Returns the schema id as JSON.
This endpoint detaches the schema from a room.
roomId
requiredID of the room