GET
Get a build

Authorizations

api-key
string
header
required

Per-project server key, prefixed sk_live_. Full access to every endpoint. Keep it on your backend: never ship it in a game binary.

Path Parameters

build_id
string
required

Build identifier.

Example:

"build_9f2c"

Response

The build.

build_id
string
required
Example:

"build_9f2c"

name
string
required

Build name. Servers reference this as version_tag.

Example:

"1.2.3"

version
integer
required

Monotonic integer version assigned per build name.

Example:

12

status
enum<string>
required
Available options:
uploading,
processing,
ready,
failed,
deleted
build_type
enum<string>
required
Available options:
zip,
docker_image
created_at
string<date-time>
required
updated_at
string<date-time>
required
executable_path
string | null

Path to the server executable inside the ZIP. zip builds only.

Example:

"Linux/GameServer.sh"

image_url
string | null

Docker image reference. docker_image builds only.

Example:

"registry.example.com/game/server:1.2.3"

error_message
string | null

Why the build failed, when status is failed. Null otherwise.

One sentence, and the whole explanation: build output is not stored. It is on every build so that a client rendering a list of builds can say what went wrong without a second call per failed row.

Example:

"No executable found at Linux/GameServer.sh"

base_version
string | null

Which Simpl base the build's entrypoint comes from: the base a zip build was built on, or the base a docker_image build was wrapped with. That entrypoint runs in front of the game, so this answers which runtime contract the build's servers get. The build is pinned to that base: publishing a newer one never changes a build that exists.

Null for builds that have not been built yet, for docker_image builds registered before Docker images were wrapped, and for some builds made before this field existed.

Example:

"2"