Selling game servers with GameAP

GameAP is a small project. On 21 August 2026 its GitHub repository had 60 stars, 9 forks and 2 contributors. That is worth saying out loud, because it sets expectations: there is no large ecosystem of billing modules, provisioning scripts and forum threads around it. If you run GameAP and want to sell what it hosts, you are mostly on your own.

This page is about closing that gap. Provibr connects to a GameAP panel and provisions, controls and imports game servers on it. Everything below was measured against a real GameAP 4.4.2 panel rather than read off a feature list, including the parts where GameAP behaves differently than you would expect.

What the integration actually covers

The two "no" rows are not oversights, and the reasons are at the end.

Step 1: the API token

GameAP authenticates with a single API token. No OAuth2 client, no key pair, no session to keep alive: one bearer, and that is the whole credential.

Four things about it matter.

It must be created by an administrator, and it must carry the create ability. GameAP tokens are scoped. A token without admin:server:create can list servers perfectly well but cannot create or delete them. That is worth knowing before your first order, because a scoped-but-wrong token looks healthy right up until a customer pays you. Provibr checks for the create ability when you test the connection, not at the first order.

Deleting hangs off that same ability. There is no server:delete scope in GameAP at all. We measured a delete succeeding with a token that carried only admin:server:create plus the ordinary server scopes. One token covers the whole lifecycle.

The token has the form id|secret. That is Laravel Sanctum shape: a numeric id, a pipe, and a 48-character secret. Provibr keeps that shape and rejects a token pasted without the id in front of it. That is a real paste mistake, and catching it beats a confusing 401 later.

It does not expire. The personal_access_tokens table in GameAP has no expires_at column. This is the cleanest long-lived credential of any panel we have integrated: the agent keeps working for months without anybody re-entering anything. Compare that with panels where the secret is a password and every rotation becomes a support ticket.

One practical note: GameAP shows the token once and stores only a hash afterwards. Copy it immediately. Provibr does not store it either, so resending credentials means minting a new token.

Step 2: transport, and being honest about it

A default GameAP install serves plain HTTP on port 8025, with 443 closed. There is no TLS fingerprint field in the credential form, because with no TLS there is no certificate to pin.

That works. It also means the API token, and everything the integration does, travels unencrypted. If that matters to you, and on a panel that holds your customers' servers it probably should, put a reverse proxy with TLS in front. The agent then validates the certificate chain normally, without a pin.

Step 3: the plan, and why there is no picklist

A GameAP server is built from a game (a title such as samp or minecraft) and a game mod, which is its template. Together they are roughly what one egg is on Pterodactyl.

Here is the sharpest difference with every other game panel we support: Provibr cannot list them for you. With a scoped agent token, /api/games, /api/game_mods and /api/nodes all return 403. Reading the catalogue is role-gated to an admin session, and no token ability unlocks it.

So there is no dropdown. You open your own GameAP panel, read the game code and the mod id, and type them into the plan. A game plan then carries that game code, that mod id and the resource limits, and ordering is plan-driven from there.

It is more typing than a picklist. It is also the honest shape: a dropdown we could not populate would be worse than a field that says what it wants.

Step 4: placement and ports

Two consequences follow from that same 403.

The node comes from a setting, not from the placement engine. Provibr ranks nodes on free capacity when it can. It cannot here, because it cannot read the node list at all. Instead the integration carries a node id, which is 1 on a single-node panel. On a multi-node panel a server lands on the node you named, and nothing is ranked.

Ports come from a range you set. GameAP has no allocation system of its own: nothing hands out a free port. The agent picks a free set of ports (game, query and RCON) from a range you configure on the integration.

What ordering actually does

This is where GameAP differs most from a panel like Pterodactyl, and where a naive integration goes wrong.

1. 01POST /api/servers writes the database record. It does not install anything.
2. 02A second call starts the install, and the panel daemon runs it as an asynchronous task.
3. 03Provibr polls that task until it reaches an end state.
4. 04Then the server starts.

The critical rule: an action's HTTP reply only means the task was queued. It does not mean it succeeded. We measured a stop that came back with an error from a race on the host. Each game server runs as its own systemd unit on the node, and systemctl stop can lose a race with itself. The task outcome is the truth; the HTTP reply is a receipt. Provibr reads the task.

Two more measured realities worth planning for. There is no external id and no idempotency key, and server names are not unique: we created two servers with the same name and got two 201s with different ids. The id returned by the create call is the only identity there is, which means a retried create silently produces a duplicate. And the install environment is not uniformly complete: a TeamSpeak 3 install on a stock panel failed because lbzip2 was missing for the .tar.bz2 extraction, while a SA-MP install on the same box ran clean. Expect "install works for one game and not another" to be a support category.

Suspending: read this before you rely on it

When Provibr suspends a game server, to enforce a capacity limit, it stops the server and marks it blocked in the panel.

Both halves are needed, and here is why: GameAP's blocked flag enforces nothing. We set blocked on a running SA-MP server and it stayed online, answering live game queries. We then sent a start to a blocked server and got a normal task back. The flag is administrative.

So Provibr stops the server to actually enforce the limit. But anyone with direct access to the GameAP panel can start it again. The block is a Provibr concept as much as a panel one, and we would rather write that down than let you discover it during your first overage.

What Provibr does not do here

No console. GameAP does have one, over a websocket, but it runs on a separate short-lived token from its own auth step and its own frame protocol, a different path than the tunnel our agent shares with the other game panels. That is real work, not a flag. Turning the tab on before the work exists would promise a tunnel that is not there.

No usage graphs. GameAP reports no per-server CPU, memory, disk or network. There is no endpoint. A graph pinned at zero looks like a measurement, and "no measurement" and "no usage" are not the same thing, so we show nothing instead.

No panel management. Nodes, files, users and the panel itself stay yours. A game server on the panel is what the integration is about.

Where this leaves a small host

If GameAP is what you run, the choice tends to get framed as "keep your panel and bill by hand" or "move to something a billing system already speaks". That is a false choice, and an expensive one: migrating a panel full of live game servers is not a weekend.

Provibr connects to control panels, hypervisors and game panels side by side. You do not have to pick one. Keep GameAP for the games you already host, add whatever you need next to it, and run the ordering, the capacity counting and the suspend-on-non-payment across all of them from one place.