Overview

The API is one Express application behind one HTTPS endpoint per environment. Every route is POST with a JSON body and a JSON response; there are no verbs to remember, only paths. This page is the part that is the same for every route — the reference pages in this section list the routes themselves, generated from the server's own route documentation.

Hosts#

Two groups live beside /api instead of under it, on the same host: /system/** (the master-only control plane, https://core.inmake.dev/system/…) and /generative/** (the twin of /api/gen that bills the shared wallet). Each reference page prints the group's real base path.

GET on the base itself (https://core.inmake.dev/api, no token) returns the live spec: version, number, env, the header contract and every route — the same document these pages are generated from. The badges at the top of each group page come from it.

Headers#

Groups#

Access evaluation#

The middleware in front of every group looks up the token, matches the request path against the token's access tree segment by segment (public → store, admin → read, …), and either lets the handler run or answers 403. Stock paths get an extra ownership check. auth/* is always allowed so a token can always inspect itself. What a route needs is therefore not printed per route — it is the route's own path.

Errors#

{
  "error": "RequestError",
  "message": "Missing required parameter: path",
  "body": { "…": "your request body, credentials removed" }
}

400 bad parameters · 401 no valid token · 402 empty wallet on a paid route · 403 the access tree said no · 404 not found · 409 conflict · 500 internal (the message is the exception). Details in Authentication › Errors.

Batch paths#

Routes that take a path (admin/read, admin/update, …) also accept a list of paths; the evaluation runs per path and the response is a list in the same order. This is how the SDK's batch calls work.

Listing and pagination#

List routes share one shape: query (a set of conditions — a scalar value is an equality shorthand), order_by ({field, direction}), limit, offset (the id of the last document you received) and mask (return a subset of fields). Page by passing the last id back as offset.

Query keys#

Equality filters alone, or a range / order_by on one field with no filter, need nothing. A listing that filters and sorts — equality on some fields, then a range or an order_by on another — runs on a query key of the collection: built in for the common shapes (below), declared for the rest as keys: {"<name>": ["<field>", …]} on the collection row (the console's collection settings; for a module, the manifest's data.collections[].collection.keys). Rule of thumb: equality on the leading fields, range or sort on the last — {"status_prep_time": ["status", "prep_time"]} serves status == public ordered by prep_time in either direction, with an optional range on it. The platform maintains a computed _k.{name} field on every document (never write it; the public routes never return it) and rewrites a matching query onto it, so no composite index is involved. Limits: up to 8 keys per collection, 1–4 fields each, no id, no _k. A query no key serves still runs while its equality part matches at most 500 documents; above that the answer is 400 {"error": "query_key_required", "collection": …, "suggest": [fields]} — suggest is the field list to declare. With the built-in keys this only happens for a shape outside them.

Built-in keys#

Most listings need nothing declared. Every content collection gets keys derived from its schema template (schema order decides "first"; up to 5, on their own budget — the 8 explicit keys are untouched):

So a recipes collection with an enum category and no date field has status_timestamp, category_timestamp and status_category_timestamp; articles with a publish_date has status_timestamp and status_publish_date. Nothing is derived for number, boolean or array fields — a "by prep_time" listing declares its own key.

The products mirror (data/{locale}/products, what a storefront lists) has a fixed set, and its array filters run on platform composite indexes instead:

One array filter per query: "category X and tag Y" is not one index — filter the second array in memory over the category page, or add a scalar field and a key. The mirror carries status and timestamp from the root product, so a product never opened in the content editor is listable too.

A built-in is disabled with keys: {"<name>": null} and overridden by declaring the same name. Built-ins backfill lazily — the first listing after they appear starts the build (building → ready; the query runs natively meanwhile).

→ the full list, generated from the index file: Indexes

Locales#

Content, slugs, templates and translations are per locale in the xx_YY form (cs_CZ). A locale the store does not declare is a 400.

Credits#

The gen/* and generative/* routes are metered; each shows its price in credits next to the path. 1 credit = $0.01 by convention. See Credits.