Authentication

The public REST endpoints in this guide authenticate a creator before they read or change game data. Only use a credential from an account authorized to manage the target game.

For MCP connection and sign-in instructions, use the canonical MCP setup guide. Do not copy setup details from old snippets or third-party pages.

Header conventions

The supported public routes use one of two header names:

Both header names authenticate the same personal credential. The different names are part of the current handler contracts, so use the one listed for the route you call.

Verify a credential

POST /api/v2/mcp/verify-access-key

Request body:

{
  "accessKey": "<personal credential>"
}

A successful response has this shape:

{
  "code": "SUCCESS",
  "data": {
    "uid": "string",
    "username": "string",
    "email": "string"
  }
}

The route returns 400 when accessKey is missing and 403 when it cannot be verified.

Permission model

A valid credential is not enough by itself to change every game:

• Creating a game creates it for the authenticated creator.
• Duplicating a game requires ownership.
• Updating metadata, downloading room data, importing room data, and reading build items require authorization to manage that game.
• A permission failure should stop the workflow. Do not retry with a different game identifier until you have confirmed access.

Keep credentials private

Never place a personal credential in client-side JavaScript, a public repository, a room-data file, a temporary upload destination, a screenshot, or a support request. Keep it in the secure environment supported by your MCP client or server-side integration.

If a credential may have been exposed, use the account flow described by MCP setup before continuing.