> For the complete documentation index, see [llms.txt](https://sdk.metamarket.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sdk.metamarket.tech/overview/product-in-practice.md).

# Product in Practice

This page brings the working parts of MetaMarket together: what is implemented, one flow from sign-in to a state change, how integration works today, and where each capability is documented.

## What is implemented

The core engine and integration surface are already used by MetaMarket's own games. Each item links to the page that documents its real interface.

* **Identity and device authentication.** A player is a durable account; a device proves possession of an on-device key before it is issued a session. See [Authentication](/evaluate-and-integrate/authentication.md).
* **Actions and state.** A game reports actions; the engine evaluates each against the app's configuration and holds authoritative state. See [Sending Actions](/evaluate-and-integrate/events-and-directives.md) and [Reading State](/evaluate-and-integrate/reading-state.md).
* **Quests and progression.** An accept-to-complete lifecycle with staged, sequential, and parallel orchestration. See [Quests and Progression](/core-concepts/quests-and-progression.md).
* **Rewards, resources, quotas, inventory.** One reward-package delivery path, resources that settle on read, refillable quotas, and an inventory. See [Rewards and Inventory](/core-concepts/rewards-and-inventory.md) and [Resources and Quotas](/core-concepts/resources-and-quotas.md).
* **Local and shared economy.** Per-game currencies plus a platform currency and loyalty standing a game feeds through platform-owned quests but cannot mint or read. See [Local and Shared Economies](/core-concepts/shared-economy.md).
* **Configuration.** A game's mechanics are a typed configuration document the engine reads per request. See [App Configuration](/evaluate-and-integrate/app-configuration.md).
* **The .NET SDK and HTTP API.** A typed .NET client and the raw endpoints under `/api/*`. See [SDK Guide](/evaluate-and-integrate/sdk-guide.md) and [HTTP API](/evaluate-and-integrate/api-guide.md).

For the exact status of each, [Product availability](/overview/current-scope.md) is canonical.

## One complete flow

A real path from an empty client to a state change, using the actual routes and response shapes. It shows what a partner can observe end to end: sign-in, an action, the resulting local state, and the milestone report that hands off to the platform. The platform-side grant that milestone triggers is described where it happens rather than shown as an integrator-visible response, because a game cannot read the shared balance. This is what MetaMarket's own pet-care game does.

1. **The game is registered.** MetaMarket provisions the app id, the gateway address, and the app's configuration (its allowed actions and resources). Registration is assisted today; see [Getting access](/evaluate-and-integrate/getting-access.md).
2. **A player authenticates.** The client generates a device key and calls `POST /api/auth/device-login`. An unknown device is bootstrapped as a guest; the response is `{ accessToken, refreshToken, accessTokenExpiresAt }`, with an RS256 access token on a 15-minute lifetime.
3. **The session starts.** `POST /api/session/start` returns the app's `start_session_directives`. Running one of those directives (a `track_actions` call) opens the pet game's starter package, and its contents come back in that call's `effects`, not in the `session/start` response.
4. **The game reports an action.** A `care` action on the pet:

```json
POST /api/events/track
[{ "playerId": "…", "actionType": "care", "value": 5, "clientKey": "care-1", "timestamp": "2026-07-17T10:00:00Z", "entityId": "pet-a" }]
```

5. **The engine evaluates it against configuration.** `care` is a declared action that writes the pet's `growth` resource. An action the app's config does not declare is not applied: it comes back counted in `skipped` with HTTP 200, not an error.
6. **State changes, and a quest reacts.** The write moves `growth`. A staged "grow your pet" quest checks `growth` as an absolute condition, and its final task becomes claimable on the quest's next evaluation, not inside this action's response.

**Before.** The pet's `growth` resource is at 95.

**Action.** The `care` action with value 5, shown above.

**Response** (the real four-channel envelope):

```json
{
  "data": { "processed": 1, "skipped": 0 },
  "effects": [{ "entityId": "pet-a", "key": "growth", "kind": "absolute", "value": 100 }],
  "mutations": [],
  "directives": []
}
```

**After.** `growth` is 100. The `effects` channel echoes the new absolute value, so the client updates without a second read; the staged quest's absolute check passes on its next evaluation, when its final task becomes claimable. What the integrator can observe ends there. A platform-owned bridge quest reacts to the milestone on the platform side and may credit the shared currency, but that grant does not appear in the game's response and is confirmed on platform-operated surfaces, not by the integrator.

7. **The game reads state.** `GET /api/player/state` returns the player's composite state, current at read time.
8. **An error or skip is handled.** A spend a resource cannot cover (a `use` on an exhausted quota) returns `400` with a stable `code`; an undeclared or wrong-lane action is not applied and shows up in `skipped`. See [Treat a non-zero skipped as a failure](/evaluate-and-integrate/events-and-directives.md#treat-a-non-zero-skipped-as-a-failure).
9. **The activity is recorded.** Each action, reward, and economy movement is written to the platform's operational logs for monitoring and investigation.

This flow covers the game-side chain, from sign-in through the milestone report. The platform-side GG or loyalty grant that milestone triggers is not shown here, because a game cannot read the shared balance; its status is on [Product availability](/overview/current-scope.md), where it is marked platform-operated and proven in MetaMarket's own games. The full requests and responses for the game-side steps are in [Worked Examples](/evaluate-and-integrate/examples.md). Running them is not self-service: the [Integration walkthrough](/evaluate-and-integrate/quickstart.md) is the same flow you run once assisted onboarding has provided an app id, the SDK, and a test environment.

## How integration works today

MetaMarket is at an assisted-integration stage, and the docs say so rather than implying self-service. A studio is onboarded with the team: the app is registered, its configuration is prepared and reviewed together, and a test environment is provided. The typed .NET SDK is delivered at onboarding rather than from a public package feed, and any stack integrates over the HTTP API. [Evaluate MetaMarket](/evaluate-and-integrate/evaluate.md) is the process; [Product availability](/overview/current-scope.md) is the maturity of each capability.

## What these links do and do not show

Each capability above links to the page documenting its real interface, which is what lets you check the description against the contract rather than take it on trust. They do not establish production usage at scale. Where something is proven only in MetaMarket's own games, [Product Availability](/overview/current-scope.md) says so on the row for that capability.

## What is planned

Planned work is on the [Roadmap](/releases-and-reference/roadmap.md), kept separate from what runs today.