API Tooling

Machine-readable CGSP v1.1: an interactive API Explorer in the browser, a Postman collection to call the endpoints from a desktop app, and OpenAPI specs to generate code. All match the Protocol Reference exactly and are the same files used to validate the docs.

Want to…	Use
Browse and send requests in the browser, nothing to install	API Explorer
Call endpoints from a desktop app	Postman collection
Generate a server stub for the service	OpenAPI — Game Service
Generate a client for the platform calls	OpenAPI — Platform

API Explorer

The portal ships its own interactive console — open /api-explorer/ to browse every endpoint, read the schemas, and send requests to your own running stack, with nothing to install and no account.

It is fully self-hosted: the rendering engine and the OpenAPI specs are served by this site, not a third-party cloud.

Where requests go

The Explorer sends requests from the browser to the base URL shown in each spec — http://localhost:7000 (platform) and http://localhost:3030 (service) by default. Point them at a running local stack (see the Quickstart), and make sure the target sends CORS headers — a desktop app like Postman is not subject to CORS, which is why the downloadable collection below stays useful.

Postman collection

Every CGSP v1.1 endpoint in one importable collection, grouped by the four protocol surfaces.

Download

File	Purpose
cloud1x2-cgsp.postman_collection.json	The collection — all endpoints
cloud1x2-cgsp.postman_environment.json	A local environment (base URLs + secrets + sample IDs)

In Postman: Import → drop both files in → select the Cloud1x2 CGSP — Local environment in the top-right picker. The same JSON also imports into Insomnia or Bruno, or feeds curl for offline use.

Two base URLs

CGSP endpoints flow in two directions, so the collection uses two base URLs:

Variable	Default	Used by
serviceBaseUrl	http://localhost:3030	Control Plane — endpoints the game service hosts. Sending these simulates the platform driving the service.
platformBaseUrl	http://localhost:7000	Config + Ledger, Launch Verification, Wallet — endpoints the platform hosts. Sending these simulates the service calling the platform.

Folders

Folder	Surface	Direction	Auth header
1. Control Plane	Control Plane	Platform → Service	x-internal-control-secret
2. Config + Ledger	Config + Ledger	Service → Platform	x-internal-config-secret / x-internal-wallet-secret
3. Launch Verification	Launch Verification	Service → Platform	x-internal-verify-launch-secret
4. Wallet	Wallet API	Service → Platform → Operator	x-internal-wallet-secret

Variables

The collection ships with sample values so every request runs without editing. Override them in the environment to point at a real service or platform.

Variable	Default	Meaning
controlSecret, configSecret, walletSecret, verifyLaunchSecret	dev	The four internal auth secrets
serviceUid	wp9dvdgp4wfqmxq4	The service’s 16-char wire identity
engineId	wp9dvdgp4wfqmxq4:p:42	A sample engine identity
runtimeProfileId	42	A sample runtime profile
gameExternalId	9000	A sample game
betUid	wp9dvdgp4wfqmxq4-01krr…	A sample bet UID (drives trxIds)
partnerId, operatorId, currency, customer, playerToken	sample	Launch / wallet context

Path variable: engineId

For the engine status / pause / resume requests, :engineId must be URL-encoded (: → %3A), e.g. wp9dvdgp4wfqmxq4%3Ap%3A42. Postman encodes the path variable automatically when sending.

A quick end-to-end run

Against a running platform + service (see the Quickstart), the endpoints exercise a full bet:

1. Control Plane → PUT desired-state — bring the engine up.
2. Launch Verification → verify-launch (demo) — open a session.
3. Config + Ledger → POST consolidated/tx — open the ledger for a bet.
4. Config + Ledger → POST consolidated/tx/settle — settle it.

For real-money flows, add the Wallet folder’s debit → credit between steps 3 and 4. Remember: wallet calls return a two-layer response — check httpOk, not just ok (see the Wallet API).

OpenAPI specs

For code generation and AI agents, CGSP is also published as OpenAPI 3.1. The protocol is split into two specs because it flows in two directions — each has a single server URL, which keeps generated code clean.

Spec	Describes	Generate
cgsp-game-service.openapi.yaml	The control plane the service hosts	A server stub to implement
cgsp-platform.openapi.yaml	The platform endpoints the service calls	A client to call

The gameplay WebSocket surface (Socket.IO) is not in OpenAPI — it is not a request/response HTTP API. See the Gameplay Protocol.

Generate code

With openapi-generator (any target language):

# A server stub for the service to implement (Node + Express shown)
npx @openapitools/openapi-generator-cli generate \
  -i https://<portal-host>/cgsp-game-service.openapi.yaml \
  -g nodejs-express-server -o ./cgsp-server

# A typed client for the platform calls (TypeScript shown)
npx @openapitools/openapi-generator-cli generate \
  -i https://<portal-host>/cgsp-platform.openapi.yaml \
  -g typescript-fetch -o ./cgsp-client

Both specs validate as OpenAPI 3.1 and can be loaded into Swagger UI, Redoc, Stoplight, or imported directly into Postman (Import → API keeps them as a spec rather than a static collection).

One source of truth

The repository YAML is canonical. The Postman collection can be regenerated from the platform spec (openapi2postmanv2 -s cgsp-platform.openapi.yaml), so the two never drift.