BirdHouse Matchmaking groups players using rules your game server sends with each ticket: match size, mode, parties, and skill windows that widen as players wait. It returns the matched group; your game reserves the server and moves the players. Roblox servers use the Luau SDK, and other game servers use the HTTP API.
-- Configured client, current player, sample skill.
local session = client:CreateSession({
players = {{ id = tostring(player.UserId) }},
meta = { mode = "ranked", skill = 1200 },
constraints = {
type = "and",
constraints = {
-- Four players, same mode.
{ type = "playerCount", min = 4, max = 4 },
{ type = "fieldEqualsDeep", field = "mode" },
-- Widen the skill range as players wait.
{
type = "fieldWindow", field = "skill",
min = 50, max = 200, spreadRate = 2,
},
},
},
})Combine rules with AND, OR, and NOT. Every ticket’s rules must pass.
SDK rule example with illustrative values. A configured client and current player are required.
A ticket carries players, metadata, and the rules it needs a match to satisfy. BirdHouse evaluates candidate groups against every ticket’s rules.
Queue an individual player or an entire party with your game’s constraints.
A group can match only when all of its tickets accept it. Player counts include everyone in each ticket.
Your server receives the matched group, then handles server reservation and player handoff.
Combine constraints with AND, OR, and NOT. Put the matching policy in your ticket payload, where your server can control it.
Set a minimum and maximum group size. The matcher publishes the first group that satisfies every ticket and does not wait to fill a range toward its maximum, so use the same number for both when you need a fixed lobby size. A party stays in one ticket, so its players are matched together.
Start with a narrow skill range, then widen it as a ticket waits. You supply the skill value; BirdHouse compares it. Each ticket’s window must accept the group; one player waiting longer does not override another player’s rules.
Use ticket metadata for conditions such as mode or region. Separate environments keep queues isolated: tickets from different environments never match, even after their rules relax with wait time.
The example above combines player count, mode, and an expanding skill window. Your constraints define what makes a valid match; the docs cover the complete rule schema.
Matchmaking runs as a service your game server calls. Player devices should never call it directly.
A server Script creates a ticket for each player or party, the SDK batches heartbeats while they wait, and an event fires when a match is ready. Servers that use the same service endpoint and environment share one queue, so players in different servers of your experience can match. The experience needs HTTP requests enabled.
Roblox SDK referenceOne JSON endpoint accepts three actions: create, confirm, and cancel. Call it from a dedicated game server or backend you control, in any language. Roblox is the only SDK today, and the API has no access-token authentication in this phase, so do not call it from player devices.
HTTP API referenceCreate a session and handle the match event in your game. This example uses the Luau SDK on a Roblox server.
-- Using a configured client.
local session = client:CreateSession({
players = {{ id = tostring(player.UserId) }},
constraints = {
type = "playerCount",
min = 2,
max = 2,
},
})
session.Matched:Connect(function(match)
-- Reserve a server and hand off the players.
print("Match ready", match.id)
end)This example starts with a configured client. To run it you need a service endpoint with an enabled environment and, on Roblox, the SDK package. These are arranged with the team during early access. You enable HTTP requests yourself in your experience’s settings. The docs describe SDK version 0.4.0 and do not confirm a published package or a hosted service.
BirdHouse returns a matched group. Your game owns server reservation, teleportation, and recovery if that handoff fails. Applying does not provision a service or create an account.
Matchmaking forms the group. These parts stay in your game, so plan for them before you integrate.
Matchmaking is in early access. Apply for early access and tell us about your project. A service endpoint and SDK package access require coordination with the team; submitting the form does not grant immediate access. Documentation is available now.
Yes. Matchmaking is in early access with a Luau SDK that runs in server Scripts and calls the service over HTTP. It does not run in LocalScripts. Your game still reserves the server and teleports the matched players.
There is no SDK for those engines. During early access, a dedicated game server or backend you control can call the HTTP API directly. The API has no access-token authentication in this phase, so it is not meant to be called from player devices.
No. BirdHouse returns the matched group. Your game is responsible for reserving a server and moving the players into it.
No. Your game computes and stores each player’s rating and sends a number in ticket metadata. Matching rules compare that number.
You can apply for Matchmaking early access on its own. Analytics targets Q4 2026; feature flags and configuration target Q1 2027; experiments target Q1 2027. These products are planned.
Tell us about your project and the queues you need to support.
Apply for early access Explore Analytics