Environments

Every store exists twice: once on Production and once on Demo. They are separate Firebase projects with separate data, separate tokens and separate API hosts — nothing you do on Demo can touch a live store.

Hosts#

Route groups hang off the API base: https://core.inmake.dev/api/public/store, https://core.inmake.dev/api/admin/read, and so on. Two groups sit beside /api rather than under it — the master-only /system/** control plane and /generative/**, the shared-wallet twin of /api/gen — and the MCP endpoint is POST /mcp on the host root. The API overview lists all of them.

Use Demo first. Tokens are environment-bound: a token minted on Demo is rejected on Production and vice versa. The environment switch in CRM & Studio (the blue top bar means Demo) and the Try-it rail on these pages follow the same rule.

Stores#

A store is identified by its store id (sid) — a DNS label (my-store), chosen once at creation and never renamed. It appears as the store header on every request, as the {sid} in every Firestore path (store/{sid}/…) and as the subdomain of the hosted store pages.

CRM & Studio keeps membership, roles and activity in its own database; the core API keeps the store's data. A store you can open in CRM & Studio is not automatically a store your token can read — that is the token's own access tree, see Authentication.

Locales#

Localized content is keyed by locale in the xx_YY form — cs_CZ, en_US, de_DE. A store declares its locales on the store document (locales), and every content read that takes a locale parameter must use one of them (a missing or unknown locale is a 400). Templates, translations ({{t}}) and slugs are all per locale.

Versions#

Both environments report what they run at GET {base} (the API base itself, no token): version, number (commit count) and env. The API reference pages show both badges live, so you can tell when a route is not on an environment yet.