> 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/evaluate.md).

# Evaluate MetaMarket

Evaluate MetaMarket in three stages: understand the model, prove one flow against a real environment, then agree how a launch would work. You commit to nothing until the last stage.

Onboarding runs with the MetaMarket team rather than through self-serve signup, so an evaluation is a conversation as much as a technical exercise.

## Before you talk to anyone

You can go a long way on your own. The [core concepts](/core-concepts/one-player-many-games.md) explain the model; [What you can build](/overview/capabilities.md) and the use cases show the outcomes; the [Integration walkthrough](/evaluate-and-integrate/quickstart.md) and [Worked Examples](/evaluate-and-integrate/examples.md) show real requests, responses, and the state they change. Working through those tells you whether the platform fits before a single credential changes hands.

## The evaluation, step by step

1. **Review the model and examples.** Confirm the primitives cover the mechanics you have in mind.
2. **Share your context.** The game, your technical environment, and the use case you want to prove. This is what lets the team scope a useful first flow rather than a generic demo.
3. **Technical workshop.** A working session to map your mechanics onto configuration and settle the shape of the proof of concept.
4. **Receive access.** The .NET SDK, your app id, the gateway address, and a test environment to point at. An external client holds no app secret; it authenticates the player with a device key it generates itself.
5. **Build one supported flow.** A single end-to-end path: sign a player in, send the actions your mechanic needs, read the resulting state, and confirm it behaves the way your design intends.
6. **Review production requirements.** What a live deployment needs, and the operating arrangements around it, covered in [Production Operations](/architecture-and-trust/production-operations.md) and [Trust and due diligence](/architecture-and-trust/trust-and-due-diligence.md).
7. **Agree the launch plan.** Scope, configuration, and the steps to go live.

## Who should take part

A developer to run the integration, and whoever owns the mechanics and economy design, a game designer, product manager, or economy designer, so the configuration reflects the intended experience rather than a guess at it. A technical or security reviewer can join at the production-review step, where the material in [Trust and due diligence](/architecture-and-trust/trust-and-due-diligence.md) is shared under evaluation.

## What the pilot shows, and what follows

A pilot is judged against acceptance criteria agreed for your chosen use case. A useful pilot typically shows, where they apply to your mechanic:

* a player authenticates and holds a session;
* the actions your mechanic sends are all accepted, with none silently dropped;
* quests or state progress as the design intends;
* rewards are issued correctly;
* retries and idempotency behave as documented;
* a player reaches only their own tenant's data;
* the resulting state reads back correctly;
* one error case is handled cleanly;
* you can produce the information a support request needs.

It validates that flow and environment, not every requirement your game will have; the final acceptance criteria are set for the selected use case, without a fixed timeline or commercial scope attached. From there the conversation moves to the rest of your requirements, the production configuration, and the launch plan.

When you are ready to start, [Getting access](/evaluate-and-integrate/getting-access.md) covers registration and how the SDK is delivered.