MCP & API
This reference is for advanced automation around Portals games. It deliberately documents a small, stable set of public workflows instead of treating every server route as a supported integration surface.
For a connected assistant, start with the canonical MCP setup guide. MCP is the best starting point for most creators because it can guide room editing, asset workflows, testing and iteration, and finding available free marketplace assets without making you assemble low-level requests by hand.
What the public REST API supports
| Workflow | Public contract |
|---|---|
| Confirm a personal credential | Verify a credential before starting an automated workflow. |
| Create or duplicate a game | Start from a current template or make a safe copy of a game you own. |
| Update selected game metadata | Change an explicit set of supported top-level game fields. |
| Read and import room data | Download a snapshot, make a deliberate change, then import it with a backup-first workflow. |
| Prepare JSON, GLB, or image uploads | Request a short-lived upload destination, upload the reviewed file, then use the returned location only for the supported next step. |
| Read build inventory | See the models, audio, images, and textures available to a game you are authorized to manage. |
The endpoint reference is organized by task:
Choose MCP or REST
Use MCP when you want help planning, changing, testing, or iterating on a game in a supported client. It groups its capabilities by practical workflows rather than asking you to remember routes.
Use the REST API when you are building your own integration and can safely manage request validation, error handling, backups, and a test game.
Neither path is required for ordinary no-code building. For in-game behavior, begin with Interactive Studio. For custom in-game interfaces or scripting, use Code & Custom UI.
Safety rules for automation
- Work on a disposable test game before changing a live game.
- Download room data before any import, and keep that backup until you have tested the result.
- Change the smallest supported surface possible. Use metadata updates for metadata; do not use a room-data import for a one-line title change.
- Keep personal credentials and temporary upload destinations out of browser-delivered code, public logs, screenshots, and issue reports.
- Treat room snapshots as structured data. Preserve fields you are not intentionally changing.
Base address and response style
The public base address is https://portals.to. Requests and responses use JSON unless a room-data download returns a JSON file attachment.
Successful handlers generally include a code field or a data field. Do not infer success from a response shape alone: check the HTTP status, then handle the documented response body or error code for the route you called.
What is intentionally not documented here
This is not a reference for private operations, administrative controls, session-only helpers, commerce flows, or experimental routes. If a workflow is not in this guide, do not depend on it in a public integration.