Commerce Studio

Browse every route in the API Explorer Gateway conventions

The operator surface for catalog, customers and orders. Commerce Studio has no API of its own — it renders what installed apps declare, over the 464 gateway routes the 13 commerce apps publish.

Start here

Getting started

Call one commerce route, then render your first operator screen from a manifest. Under ten minutes, no platform account for the first four steps.

Build a Commerce Studio app

Ship a cockpit.json that becomes a screen — navigation, lists, detail pages, forms, actions and widgets.

The commerce domain

Catalog

Products, the attribute data model, categories, references, assets, associations, completeness and bulk import/export.

Customers and organizations

The B2B buying side — organizations, contacts, roles, segments, value lists and storefront accounts.

Orders and fulfilment

Cart to shipment to return, the order state machine, order lists, stock and the audit feed.

Markets, pricing and rates

Markets, channels, price lists, payment methods and lifecycle, shipping rates, carriers and settings.

Commerce Studio is where the day-to-day commerce work happens: maintaining the catalog, managing organizations and their people, and running orders through their lifecycle.

It is a renderer, not a service

The name suggests a service with an API. It is not one. Commerce Studio has no API of its own, and contributes no pages of its own — its studio navigation array is deliberately empty. It is a rendering engine: every page, list, form, widget and action button an operator sees is contributed by an installed app's cockpit.json, and the studio merges those declarations into one interface.

That is why "build a Commerce Studio app" is not a side topic in this section. It is the mechanism of the whole section, and it has its own group.

There is no single commerce API

The commerce domain is 13 independent apps — products, prices, carts, orders, orderlists, customers, payments, shipping, inventories, markets, channels, pages and forms. Each owns its own entities, its own lifecycle and its own routes on the public gateway. Between them they publish 464 capability routes today.

So there is nothing called "the commerce API" to learn. You call the app that owns the entity, through the one gateway and the same conventions as everything else:

Request

curl "https://api.revenexx.com/v1/products?limit=5" \
  -H "X-Revenexx-Tenant: <TENANT_SLUG>" \
  -H "X-Revenexx-Api-Key: rvxk_..."

Header	Purpose
`X-Revenexx-Tenant`	Required. The tenant slug the request is scoped to.
`X-Revenexx-Api-Key` or `Authorization: Bearer <jwt>`	Required, one of. See Authentication.
`X-Revenexx-Market`	Optional. Accepted by 465 operations. On a write it assigns the row to a market; on most reads it is a no-op. See Markets.

Pagination, error shapes, rate limits and idempotency are the same everywhere and live in API usage.

The five groups

Group	What it owns
Catalog	What a product is, how it is shaped, how it is classified, and how bulk data gets in and out.
Customers and organizations	The buying company, the people inside it, what they may do, and how they sign in.
Orders and fulfilment	Cart → order → shipment → return, and the stock those movements consume.
Markets, pricing and rates	The configuration every price, tax, payment option and delivery quote resolves against.
Build a Commerce Studio app	Ship a manifest that becomes a screen.

Where to go next

Getting started — one API call, then one rendered screen.
API Explorer — every one of the 464 routes, ready to try in the browser.
App Studio — manifest.json, schema.json, capabilities and permissions, which this section links to rather than repeats.
Integration Studio — move this data to and from external systems.