> 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/evaluate-and-integrate/reading-state.md).

# Reading State

You read player state for the whole picture, or to cover what an action response does not: on startup, when a screen opens, or during a reconciliation check. Much of the time you can skip it, because an action's response already carries what it changed, so a health bar or a currency counter updates straight from the reply.

## Composite player state

```
GET /api/player/state
X-App-Id: your-app-id
Authorization: Bearer <player JWT>
```

This returns the player's current state for your game in one document: their resources and their entities. It comes back as the domain result directly, with no envelope to unwrap, because there is nothing for the client to act on beyond the data. State is current when you read it: values that regenerate or decay are settled to the moment of the read.

A connected game sees its own scope. The shared platform currency and loyalty standing are folded in only on platform-operated surfaces, not on a game's own read, which is the same boundary described in [Local and Shared Economies](/core-concepts/shared-economy.md).

## Content the player holds

Two reads cover what a player has to interact with:

```
GET /api/player/items       # quests, shop items, listings, and other deliverable content across the player's slots
GET /api/player/inventory   # boxes and items the player is holding, including unopened packages
```

Discovery returns everything, including exhausted or terminal content, and lets the client decide what to show as unavailable. To open a stored package, post to `POST /api/player/inventory/{inventoryId}/open`; the open runs the normal fulfillment and returns the result in the same envelope every mutation uses.

## Reading versus echoing

Prefer the action response when you can. After a mutation, the `effects` and `mutations` channels already carry the values and entities that changed, so a follow-up read is redundant, see [Sending Actions](/evaluate-and-integrate/events-and-directives.md) for how to fold those in. Reach for an explicit read when you need state the last action did not touch: a fresh session, a screen that shows more than the action affected, or a reconciliation check. The full envelope semantics and the exact response shapes are in the [HTTP API](/evaluate-and-integrate/api-guide.md).