API and keys

Who can call

Send it as Authorization: Bearer …. A key that isn't linked to an app gets the same 404 as for an app that doesn't exist, so app names can't be probed. Changes are recorded under the key (key:<id>), the person (user:<id>) or the environment (env:<id>).

Environment tokens

Each environment has a token (ibenv_…), derived from a server secret rather than stored. Inference Bureau puts it in the environment's code as IB_ENVIRONMENT_TOKEN, with IB_API_URL, IB_APP and IB_ENVIRONMENT, which is all createClient() needs. It also signs the calls Inference Bureau makes to the app: action runs (/_ib/actions) and app proxy requests. Production gets it at its next build. The dashboard shows it among the system variables, hidden until revealed.

Embeddings for writes made with it are billed to the team's Apps key (see Vector fields).

Records and actions

Under /v1/apps/{app}/environments/{env}, where {env} is development or production:

Keys, environment tokens and owners' or admins' sign-ins queue, cancel and retry jobs; a member's sign-in only reads the queue.

curl -X POST https://api.inferencebureau.com/v1/apps/reviews/environments/production/models/review/records/query \
  -H "Authorization: Bearer $IB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "status": { "equals": "pending" } },
    "sort": { "createdAt": "Ascending" },
    "first": 50
  }'

Bodies are JSON, at most 4 MiB (MCP messages, 512 KiB). Filters, sorting, pages and search work as in the client, which wraps these routes.

Your app's reference

Every environment has an API reference worked out from its files, the same one the console's API Reference page shows and the MCP server's get_reference returns: each model with its fields, their types, the filter operators each takes, whether it sorts and joins text search, and its description; who may read it; each action with its params (as written and as JSON Schema), whether it works on a record, who may call it, and the webhook or schedule that queues it.

A description on a field, a schema, a param or an action's options is what the reference shows for it (see Field options and Action options). Without one, the reference still describes types, filters and grants.

Apps, files and deploys

These are what ib-apps uses. Environment tokens can't call them.

Shopify

Bulk metafield edits

A metafield run changes many metafields on one installed store, up to 250,000 of them, and can be undone. Give it a CSV (owner,metafield,value[,type]), a JSON list of changes, or a filter with values; it plans first (current and new values, each checked against the store's metafield definitions), then applies in batches of 25, recording each change so undo can restore the previous values. Routes: GET and POST /v1/apps/{app}/environments/{env}/metafield-runs, GET …/{id}, GET …/{id}/changes, POST …/{id}/apply and POST …/{id}/undo. Only keys with Apps Permissions and CLI sign-ins can use them.

• Big runs. A filter, a CSV by URL (csvUrl, an https link to up to 100 MB, for a CSV bigger than the 4.5 MB a request can carry) or more than 2,500 changes is planned after the answer: POST answers 202 with the run planning, and GET …/{id} follows it to planned (or failed, with error).
• More than 2,500 changes are applied and undone with Shopify's bulk mutations, outside the store's rate limit, and current values for more than 1,000 owners of a type are read with a bulk query. While Shopify works on it, the run reads applying (or undoing) with bulk naming the step. It carries on by itself until it's done, and each change still records whether it landed.
• A run answers with at most 5,000 of its changes; total says how many it has. GET …/{id}/changes?offset=&limit=&state= pages through them (at most 5,000 at a time), or only the failed ones, say.

Errors

Errors use the API's usual shape: { error: { type, code, message, request_id } }, plus problems for a refused write and event and logs for a failed action. See the status codes.