Build your own front end on the API

Sometimes the design genuinely cannot be a theme. A brand with a strong identity, a product that needs an unusual way of being chosen, a site that is as much a portfolio as a shop. Themes exist so that most merchants never have to think about front-end code, and for a minority they are the wrong tool.

The wrong response is to rebuild commerce behind a bespoke site. Stock, orders, payments, VAT, marketplace sync and the rules that stop a sync destroying your listings are months of work with a long tail of edge cases, and none of it is the thing that makes the site special.

Commerce behind, design in front

Qwikr runs as the commerce layer and your front end talks to it. The catalogue, orders, stock and the configurator are reachable over the API, so the front end can be anything — a static site, a framework you like, a bespoke build.

Everything else keeps working exactly as it does for a themed shop. Marketplaces still receive stock. The stock record still has one owner. Orders from your custom site sit alongside Amazon and eBay orders in the same reporting.

Keys are scoped, and the scope is enforced

Every key names what it is allowed to do — read orders, write orders, read analytics — and the scope is checked at the request rather than being documentation.

The enforcement fails closed in a way worth spelling out, because it is unusual: a protected endpoint that has been added without declaring a required scope refuses the request and logs a misconfiguration, rather than allowing it. The safe default for a missing rule is no, and getting that backwards is how endpoints quietly end up public.

Practically: give a public-facing front end a read key. Keep write keys server-side. A key in browser JavaScript is a key you have published.

The configurator resolves over the API too

For made-to-order products this is the part that saves the most work. Option rules, exclusions and price resolution run server-side and are exposed to the front end, so a custom site does not reimplement the product logic in JavaScript — where it would drift from the version the workshop actually uses, and where a determined customer could edit the price.

What you take on

Being straight about this, because it is the decision:

• You own the front end. Performance, accessibility, SEO, browser support, and every future change.
• You lose the published edge storefront unless you build your own equivalent. The speed that comes free with a themed shop is now your problem.
• Checkout needs care. Payments are the least forgiving part of a bespoke build and the most expensive to get subtly wrong.

The honest recommendation: use a theme unless the design is genuinely load-bearing for the business. When it is — a brand where the site is the product — the API is the right answer, and the commerce layer being someone else’s problem is exactly what makes it affordable.

Documentation that matches the code

The API reference is generated against the routes as they exist, including which scope each one requires. A reference that has drifted from the implementation is worse than none, because it is trusted — that has happened here, and it is why the docs are now derived rather than described.