Skip to main content
The PlayFlow Cloud API gives you full programmatic control over your game server infrastructure. You can start and stop servers, upload and manage builds, configure project settings, and monitor server health — all through standard HTTP requests. The API is designed for consumption by game clients, backend services, CI/CD pipelines, and AI agents alike. Every endpoint returns predictable JSON with machine-readable status fields and clear error messages.

Full OpenAPI Reference

Explore the interactive API reference with schemas, parameters, and try-it-out functionality for every endpoint.

Prerequisites

Before you make your first request, make sure you have:
  • A PlayFlow account with an organization and a project.
  • An API key for that project (found under Project Settings in the dashboard). Use a Server API Key (pf_*) for backend and CI/CD calls, or a Client API Key (pfclient_*) for code that ships to players.
  • A processed build (status: ready) if you plan to start servers — see Upload a Build.
Deleting builds and updating project settings require a Server API Key. A Client API Key receives a 403 on those operations.

Authentication

All API endpoints (except /api/health) require an API key passed via the api-key HTTP header.

API Key Types

PlayFlow projects have two API keys, each with a different access level:
You can find and regenerate your API keys in the PlayFlow Dashboard under Project Settings.
Never expose your Server API Key in client-side code or public repositories. Use the Client API Key for any code that ships to players.

Base URL

All API requests are made to:
The canonical API version is v3. A v2 compatibility layer is available for legacy SDKs but all new integrations should target v3.

Endpoints Overview

Servers

Manage the full lifecycle of your game servers — create, inspect, update, restart, and stop.

Builds

Upload game server binaries and manage the build pipeline.

Projects

Read and update project-level configuration, and query logs across all servers.

Common Operations

List Servers

Retrieve all running servers for your project. By default, only servers with status running are returned.
Query parameters:
include_launching
boolean
default:"false"
Include servers that are still in the launching state.
include_pool
boolean
default:"false"
Include pre-warmed pool servers in the results. Pre-warmed pooling is not currently enabled, so this filter returns nothing today; every server cold-starts on demand.
limit
integer
default:"50"
Maximum number of servers to return (1-100).
offset
integer
default:"0"
Number of servers to skip for pagination.
Response:

Start a Server

Launch a new game server instance. The server is provisioned immediately and moves through launching to running status.
Request body:
name
string
required
A display name for the server instance.
region
string
required
The deployment region. See Server Regions for the full list.
compute_size
string
default:"small"
Server instance size. One of: micro, small, medium, large, xlarge, dedicated-small, dedicated-medium, dedicated-large, dedicated-xlarge. See Pricing & Plan Types for specs.
version_tag
string
The build name to deploy. Defaults to the latest build if not specified.
version
integer
A specific build version number. If omitted, the latest version for the given version_tag is used.
startup_args
string
Command-line arguments passed to your game server executable on launch.
ttl
integer
Time-to-live in seconds (60-86400). The server automatically stops after this duration.
auto_restart
boolean
default:"false"
If true, the server restarts automatically if the game process exits.
custom_data
object
Arbitrary key-value data attached to the server. Useful for passing map names, game modes, or match metadata to your game server at runtime.
match_id
string
An optional match identifier to associate this server with a specific match or lobby.
environment_variables
object
Key-value string pairs set as environment variables on the server instance.
port_configs
array
Override the project-level port configuration for this server. Each entry specifies a name, internal_port, protocol (udp or tcp), and optional tls_enabled flag.
Response (201 Created):
The server starts in launching status. Once the game process is ready, the status changes to running and started_at is populated. You can poll GET /v3/servers/:instance_id or use include_launching=true when listing servers to track this transition.
Always read the connection host and port from network_ports[] in the live API response — never hardcode them. The proxy allocates a fresh external_port per server (it is not the same as your internal_port, and it is not a fixed value like 7777). TCP ports resolve through a relay hostname (relay.computeflow.cloud); UDP ports return a raw proxy IPv4 address. Read host + external_port together for each port your client needs.

Stop a Server

Shut down a running server and release its resources.
Query parameters:
shutdown_reason
string
An optional reason for stopping the server, recorded for logging purposes.
Response: The status field is a human-readable confirmation message, not a state enum — do not branch on it matching "stopped".

Upload a Build

Uploading a build is a two-step process: request a presigned upload URL, then upload your ZIP file. Processing starts automatically when the upload finishes.
1

Request an upload URL

Call the upload-url endpoint to get a presigned R2 URL and a build_id.The executable_path query parameter is optional. If omitted, PlayFlow runs Server.x86_64 inside your ZIP. Set it when your server binary has a different name.
Response (201 Created):
The presigned upload_url expires 60 minutes after it is issued.
2

Upload your ZIP file

Use the presigned URL to upload your game server build as a ZIP archive. Processing begins automatically once the upload completes.
3

Poll for status

Poll GET /v3/builds/{build_id} until status is ready (or failed).
You can track build progress by polling GET /v3/builds/:build_id or by streaming build logs from GET /v3/builds/:build_id/logs.

Create a Build from Docker Image

If you already have a containerized game server, you can create a build directly from a Docker image instead of uploading a ZIP.
name
string
default:"default"
The build name (used as the version_tag when starting servers).
image_url
string
required
The full Docker image URL including tag.
executable_path
string
Path to the game server executable inside the container.
registry_credentials
object
Credentials for private registries. Include username and password fields.

Response Shapes

Server Object

Every server endpoint returns or includes the following shape:

Build Object


Server Logs and Metrics

Server Logs

Retrieve stdout/stderr logs from a running or recently stopped server.
start_time
string
ISO 8601 timestamp to begin retrieving logs from.
end_time
string
ISO 8601 timestamp to stop retrieving logs at.
Filter to log lines containing this substring.
level
string
Filter by log level (e.g. info, warn, error).
limit
integer
default:"1000"
Number of log entries to return (1-1000).
Response:

Server Metrics

Retrieve CPU, memory, network, and connection metrics for a running server.
period
string
default:"1h"
Time window for metrics. One of: 5m, 15m, 1h, 6h, 24h.
step
string
default:"60s"
Resolution between data points. One of: 15s, 30s, 60s, 300s.
Response:

Error Handling

All error responses share a consistent JSON structure:

Common Status Codes

Validation Errors

When request validation fails, the response includes structured error details:

Rate Limiting

The API uses token-bucket rate limiting per API key. Rate limit status is returned in response headers. Response headers: When the rate limit is exceeded, you receive a 429 response:

Regions

Deploy your servers across 13 global regions for low-latency gameplay. Pass any of these region IDs to the region field when starting a server. See Server Regions for the full details on each region.

SDK and Tooling

Unity SDK

Use the PlayFlow Unity SDK for C# wrappers around the REST API, including server management from your game client.

Interactive API Reference

Explore every endpoint with the full OpenAPI specification, request/response schemas, and a try-it-out console.