Skip to main content
Admin routes let operators provision traders, inspect exchange state, broadcast messages, and control trading globally. All admin endpoints require a bearer token configured at startup.

Environment configuration

The exchange process reads its configuration from environment variables at startup. All variables have defaults.
Always set ADMIN_API_TOKEN to a strong secret before deploying to any shared or public environment. The default local-admin-token value grants full operator access.

Admin authentication

Every admin request must include the ADMIN_API_TOKEN value set at startup as a bearer token:
The token is read from the ADMIN_API_TOKEN environment variable when the exchange process starts. There is no way to rotate it without restarting the process.

User provisioning

Provision a trader

Use POST /api/v1/admin/users to create a new competition trader. Each provisioned user receives a unique API key used for all subsequent trader-facing authentication.
1

Send the provision request

2

Receive the trader profile

The response includes the trader_id, username, generated api_key, and created_at timestamp:
3

Distribute the API key to the trader

Share the api_key with the team. They use it in the x-api-key header for all REST requests and in the WebSocket authenticate message. Store it securely — it is not recoverable after provisioning.
Usernames must be unique. Attempting to provision a second user with the same username returns 409 Conflict.

Reset all users

POST /api/v1/admin/users/reset clears all user positions, open orders, and fills. User accounts and API keys are preserved — only trading state is erased.
This operation is irreversible. All positions, orders, and fill history are permanently deleted for every trader on the exchange. Use only in a controlled pre-competition reset or testing scenario.
Example response:
Connected WebSocket clients receive a resync_required system event after the reset.

Exchange state inspection

GET /api/v1/admin/state returns a full snapshot of the exchange: current trading controls, all market definitions, recent admin messages, and persistence backend status.
Example response shape:

Trading control

Trading can be enabled or disabled globally. When trading is disabled, new order submissions are rejected. Orders that are already in-flight at the moment trading is stopped still process normally.

Start trading

Stop trading

Both endpoints return the updated ExchangeControls object:

Admin messages

Admin messages can be broadcast to all connected traders or targeted at a specific username. Delivered messages appear as admin_message events on connected WebSocket clients.

Send a message

POST /api/v1/admin/messages accepts the following fields: Broadcast to all traders:
Target a specific trader:
Messages sent to a specific target_username are routed only to that trader’s WebSocket session. Broadcast messages (where target_username is null) are delivered to all connected clients.

Retrieve recent messages

Returns a list of recent AdminMessageEntry objects in reverse-chronological order.

Bulk config load

POST /api/v1/admin/config/load applies a complete exchange configuration — trading controls and all market definitions — in a single call. This is the recommended way to initialise the exchange before a competition round.
The response includes the applied controls and the full list of resulting markets. If trading_enabled is omitted, the existing value is preserved.

Leaderboard

GET /api/v1/admin/leaderboard returns the full leaderboard ranked by marked net PnL. Unlike the trader-facing leaderboard, this endpoint has no rate limiting and returns all traders.
Example response:
Net PnL is computed using settled prices for settled markets, mid-price of the best bid/ask when both sides are present, best available one-sided quote when only one side exists, or reference_price as a fallback.