Connect commerce data

A storefront gets its data from the platform's public API at https://api.revenexx.com — but never directly from the browser. Between the two sits a server layer of your own, the backend-for-frontend, and every platform call goes through it.

That one rule shapes everything in this group. It is what keeps the API key server-side, what lets one deployment serve many tenants, and what lets you shape a response for the page that's rendering instead of making the browser stitch three calls together.

The shape of it

browser  →  /api/*  on your own origin      (your server routes — the BFF)
                ↓
         https://api.revenexx.com/v1/*      (the public gateway)
                ↓
     Products · Prices · Inventory · Carts · Orders · Customers · Pages · Storage

Two things about this are easy to get wrong, and both are worth stating plainly:

• Page content does not come from Cockpit at request time. Cockpit is where an editor composes a page; the storefront reads the published result from the pages delivery surface.
• The browser never calls the gateway. If a component fetches api.revenexx.com, the credential has to be in the browser — which is the one thing that must never happen.

You start with none of it wired up

Every domain in this group resolves through a service key that defaults to mock. So the order of work on a real project is: build the surface against fixtures, then flip that domain to api when you're ready to see the customer's real data. You don't need any of this configured to start.

Where to go next

• The BFF pattern — the rule and the reasons, with the cart as the worked example.
• Authentication — the headers every call carries, and buyer identity versus admin identity.
• Multi-tenant themes — the three rules for one deployment serving many customers.
• Catalog, cart and checkout — the commerce surfaces and what backs each.
• Search, Media and assets, Forms — the rest.