> ## Documentation Index > Fetch the complete documentation index at: https://docs.playflowcloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Subscribe to lobby events (SSE) > Opens a Server-Sent Events (SSE) stream for real-time lobby updates. The caller is identified by `x-player-id`. **Event types:** | Event | Description | Frequency | |-|-|-| | `connected` | Initial event with full lobby state | Once on connect | | `lobby_updated` | Lobby state changed (player joined/left, settings changed, game started, etc.) | On every change | | `lobby_deleted` | Lobby was deleted (all players left or timeout) | Once, then stream closes | | `queue_stats` | Live matchmaking queue statistics | Every 10s while `in_queue` | | `ping` | Keep-alive heartbeat | Every 30s | **Usage (JavaScript):** ```javascript const es = new EventSource('/api/v3/lobbies/casual/me/events', { headers: { 'api-key': 'pf_...', 'x-player-id': 'player123' } }); es.addEventListener('lobby_updated', (e) => { const lobby = JSON.parse(e.data); updateUI(lobby); }); ``` **Connection lifecycle:** The stream stays open until the client disconnects, the lobby is deleted, or the player is kicked. Reconnect automatically on disconnect. ## OpenAPI ````yaml https://api.computeflow.cloud/api/doc get /api/v3/lobbies/{config}/me/events openapi: 3.1.0 info: title: PlayFlow API version: 3.0.0 description: > PlayFlow is a game server hosting and orchestration platform. Deploy, manage, and scale multiplayer game servers globally with built-in matchmaking, lobby management, and billing. ## Authentication All API endpoints (except Health) require the `api-key` header: ``` api-key: pf_your_project_api_key ``` Find your API key in the PlayFlow dashboard under **Project Settings**. Each project has a server key (`pf_...`) for privileged operations and a client key (`pfclient_...`) for game client integrations. Both work in the `api-key` header. ## Quick Start 1. **Upload a build**: `POST /v3/builds/upload-url` → get presigned URL → `PUT` your ZIP → processing starts automatically 2. **Start a server**: `POST /v3/servers/start` → get connection info in `network_ports` 3. **Connect your game client**: Use `host:external_port` from the response ## Key Concepts - **Builds**: Your game server binary packaged as a ZIP or Docker image. Versioned per name per project. - **Servers**: Running game server instances. Each gets dedicated compute and network ports with automatic health monitoring. - **Pool Servers**: Pre-provisioned servers for instant startup (~5s vs ~30s cold start). - **Regions**: 12 global regions (us-east, us-west, eu-north, eu-west, eu-uk, ap-south, sea, ap-north, ap-southeast, south-africa, south-america-brazil, south-america-chile). - **Compute Sizes**: From micro (512MB) to dedicated-xlarge (16GB dedicated CPU). ## Server Lifecycle `launching` → `running` (game ports open) → `stopped` (game exits, TTL expires, or manual stop) ## Build Lifecycle `uploading` → `processing` (build pipeline creates deployable image) → `ready` | `failed` ## Rate Limits - General reads: 100 req/sec per API key - Write operations (start server, upload build): 10 req/sec per API key - Headers: `X-RateLimit-Limit`, `X-RateLimit-Remaining` ## Plan Limits - **Free**: 1 server max, forced 1hr TTL, small size only - **Pro**: Unlimited servers, all sizes, custom TTL, pool servers ## Error Format All errors return: `{ "error": "message", "detail": "context", "status": 404 }` servers: - url: https://api.computeflow.cloud security: - ApiKeyAuth: [] tags: - name: Servers description: >- Create, manage, and monitor game server instances. Each server gets dedicated compute, network ports, and automatic health monitoring with TTL enforcement. Servers start in `launching` status and transition to `running` when the game opens its ports. - name: Builds description: >- Upload and manage game server builds. Supports ZIP uploads (automatically processed into deployable images) and direct Docker image references. Builds are versioned per name per project — uploading a new build with the same name auto-increments the version. Servers always use the latest `ready` build unless a specific version is pinned. - name: Projects description: >- Configure project-level settings including network ports, player authentication, environment variables, server pooling, and lobby/matchmaking rules. Settings apply as defaults to all servers in the project and can be overridden per-server at start time. - name: Lobbies description: >- Player-centric lobby and matchmaking system. Every request identifies the player via the `x-player-id` header. Use `/me` endpoints to interact with your current lobby — the API resolves which lobby you're in automatically. **Quick start:** `POST /v3/lobbies/default` creates a lobby with sensible defaults (no dashboard config needed). Share the invite `code` with friends, or use `POST /v3/lobbies/default/me/matchmaking` to find opponents automatically. **Matchmaking** supports symmetric teams (2v2, 5v5), asymmetric roles (1 monster vs 5 hunters), FFA, battle royale duos, and skill-based matching with auto-expanding MMR buckets. paths: /api/v3/lobbies/{config}/me/events: get: tags: - Lobbies summary: Subscribe to lobby events (SSE) description: >- Opens a Server-Sent Events (SSE) stream for real-time lobby updates. The caller is identified by `x-player-id`. **Event types:** | Event | Description | Frequency | |-|-|-| | `connected` | Initial event with full lobby state | Once on connect | | `lobby_updated` | Lobby state changed (player joined/left, settings changed, game started, etc.) | On every change | | `lobby_deleted` | Lobby was deleted (all players left or timeout) | Once, then stream closes | | `queue_stats` | Live matchmaking queue statistics | Every 10s while `in_queue` | | `ping` | Keep-alive heartbeat | Every 30s | **Usage (JavaScript):** ```javascript const es = new EventSource('/api/v3/lobbies/casual/me/events', { headers: { 'api-key': 'pf_...', 'x-player-id': 'player123' } }); es.addEventListener('lobby_updated', (e) => { const lobby = JSON.parse(e.data); updateUI(lobby); }); ``` **Connection lifecycle:** The stream stays open until the client disconnects, the lobby is deleted, or the player is kicked. Reconnect automatically on disconnect. operationId: lobbyEvents parameters: - schema: type: string description: Lobby configuration name or ID. required: true description: Lobby configuration name or ID. name: config in: path - schema: type: string description: Unique player identifier. required: true description: Unique player identifier. name: x-player-id in: header responses: '200': description: SSE stream opened. Events are sent as `text/event-stream`. '400': description: Missing x-player-id header. content: application/json: schema: type: object properties: error: type: string description: Human-readable error message describing what went wrong. detail: type: string description: >- Additional error context. May contain the same text as error or more specific technical details. status: type: number description: HTTP status code (matches the response status code). required: - error - status description: >- Standard error response returned by all API endpoints on failure. '404': description: You are not in a lobby. content: application/json: schema: type: object properties: error: type: string description: Human-readable error message describing what went wrong. detail: type: string description: >- Additional error context. May contain the same text as error or more specific technical details. status: type: number description: HTTP status code (matches the response status code). required: - error - status description: >- Standard error response returned by all API endpoints on failure. components: securitySchemes: ApiKeyAuth: type: apiKey in: header name: api-key ````