Currencies · inventory · trusted rewards

Let the game client read economy state. Keep the mint on the server.

Define currencies and virtual items once, read a player's balances and inventory at runtime, and apply signed reward/sink/item deltas atomically from trusted game-server code. Player tokens cannot call the mutation route.

Create a free economy project → Inspect economy endpoints
Trusted mutation 
POST .../players/{player_id}/economy/adjust
Authorization: ServerToken ...

{
  "balance_adjustments": [
    {"currency_key":"gold","amount":50}
  ],
  "inventory_adjustments": [
    {"item_key":"sword","quantity":1}
  ]
}
Verify before you integrate

The trust boundary is enforced by the route, not by convention.

The public contract and router agree: economy reads can use a player or server identity, while adjustments require trusted server authority. The dashboard is for defining currency/item catalogs; reward mutation belongs in authoritative game-server logic.

Live API status

A live check of the hosted API right now. No made-up uptime percentage and no hidden demo environment.

Check current status

Public API contract

The hosted HTTP surface is documented as OpenAPI. Inspect the wire format before choosing an SDK or writing an adapter.

Open the spec

MIT client SDKs

The JavaScript, Godot, Unity, and Roblox client SDK source is public. The hosted backend itself remains a managed proprietary service.

Inspect the SDK source

Documented exit path

Read what is exportable today and the written commitment for advance notice plus an export window if the hosted service winds down.

Read the exit guarantee

Seasonal rewards without client-side minting

See how leaderboard results and economy rewards fit together when score authority and reward authority stay server-side.

Read the economy + leaderboard guide
01

Define stable keys

Create project-level currencies such as gold and items such as sword_01. Runtime adjustments refer to those stable keys rather than database ids.

02

Read player state

Authenticated players can read their economy; server tokens can read on behalf of players. That keeps UI rendering separate from reward authority.

03

Adjust atomically

Apply multiple signed balance and inventory deltas in one request and one transaction. Use it for match rewards, sinks, consumables and grants.

Security boundary

A free guest token must never be a money printer.

Anonymous player authentication is intentionally low-friction, so it cannot be trusted to award gold, premium currency or items. Crux's adjustment route requires ServerToken; put rewards behind authoritative server logic and ship only player-safe credentials to clients.

See the credential boundary
Product boundary

Economy state is not a storefront.

Crux stores virtual currency and inventory state. It does not currently provide store offers, real-money checkout, receipt validation, price localization, segmentation, or promotion tooling. Keep platform commerce and payment validation separate.

Compare a broader economy stack
First useful test

Award one server-authoritative match reward and inspect the player state.

Create a currency, run Quickstart from outside the dashboard, then use a server token to grant that player a small reward. Confirm the client can read the new balance but cannot call the adjustment endpoint itself.

Run the economy flow → Pair rewards with leaderboards