> 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/readme.md). # MetaMarket MetaMarket is a backend for studios that will ship more than one game. It replaces the engagement and economy services a team otherwise rebuilds per title, and it keeps one player relationship across all of them. It does two jobs, and they are worth separating. The first is per-game infrastructure. Quests, progression, rewards, inventory, resources, refillable quotas, and local currencies run on one configurable engine. A studio declares its mechanics as configuration and the engine reads them on each request, so a change reaches a live game without a new backend service and without a client release. The second is the shared player layer. A person who played your first title arrives at your next one as the same player, carrying the identity they already have once they link their installs. Above that sits a platform currency and a loyalty ladder that reflect activity across every connected game. Both are operated by MetaMarket rather than by any one title: a game reports that a milestone happened and the platform decides what it is worth. No game can mint, spend, read, or configure shared value, which is what stops the newest title from devaluing it for the others. Each game keeps its gameplay, content, UX, and the balance of its own economy. Registration, configuration, and onboarding are done with the MetaMarket team rather than self-serve. **Build the first game. Reuse the foundation for every one after it.** If you are new here, [One Player, Many Games](/core-concepts/one-player-many-games.md) explains the problem underneath all of this: one player relationship spanning titles that must stay isolated from each other, and who is allowed to change what. ## What you can build Each of these is configuration on the shared engine rather than a separate service you deploy and operate: * Progression systems, achievements, daily and weekly challenges, and reward campaigns, built from a quest lifecycle and one shared reward model. See [Engagement and Loyalty](/use-cases/engagement-and-loyalty-use-cases.md). * Soft-currency economies with sinks, faucets, energy gating, and studio-run shops. See [Game Economy Infrastructure](/use-cases/game-economy.md). * Player-to-player listings and studio catalogues on the same inventory and economy. See [Marketplace Workflows](/use-cases/marketplace.md). * Portfolio-level loyalty: one tier and badge ladder a player carries across connected games. MetaMarket operates it and displays it on its own surfaces; a game feeds it by reporting milestones. See [Local and Shared Economies](/core-concepts/shared-economy.md). [Product Availability](/overview/current-scope.md) records the exact status of each of these, including which need assisted integration and which are planned. ## What your studio controls Gameplay, content, UX, art, and the balance of your economy stay yours. MetaMarket holds authoritative state, evaluates quests, delivers rewards, and owns identity, but it does not decide what a quest rewards, how a currency is tuned, or how any of it looks. [Studio and Platform Responsibilities](/architecture-and-trust/responsibilities-and-boundaries.md) draws the whole line, including where real money sits. ## Built as a working platform MetaMarket powers its own games, so the engine and its integration surface are in production use rather than described from a design document. [Product in Practice](/overview/product-in-practice.md) inventories what is implemented, walks one real flow from sign-in to a state change, and links each capability to the page that documents its actual interface. ## Where to go next Three routes through this site, depending on what you are trying to decide: * **Working out whether it fits.** [Why MetaMarket](/overview/problem-and-value.md), then [Who it's for](/overview/who-its-for.md) and [When MetaMarket is a good fit](/overview/when-good-fit.md). * **Assessing the technology.** [Architecture Overview](/architecture-and-trust/product-overview.md), then [Security and Tenant Isolation](/architecture-and-trust/security-and-tenant-isolation.md) for how the boundaries are enforced, and [Product Availability](/overview/current-scope.md) for what is real today. * **Integrating a game.** [Evaluate MetaMarket](/evaluate-and-integrate/evaluate.md) covers how an engagement starts, and the [Integration walkthrough](/evaluate-and-integrate/quickstart.md) is the first thing you build once you have access. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://sdk.metamarket.tech/overview/readme.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.