Table of Contents

Back office API

/api/admin — what the client's own staff use

What the client's own staff use to run the platform: content, settings, pricing, users, and the operational machinery underneath. Unscoped — an admin sees every customer.

Who calls it

Back-office staff at the client, through the admin UI. Every controller sits behind one policy.

Authentication Cookie session — the same session as the storefront
Authorization HostAdmin, from a claim on the signed-in user
Scope Bypass. No customer filter is applied
Contract stability Internal. It moves when the admin UI moves

One policy, not a permission model. Admin access is currently binary: you are a host admin or you are not. There is no finer grain — no "can edit content but not pricing". That is a deliberate simplification for a small back-office team, and the obvious thing to revisit when the team running the platform is larger than the team that built it.

Warning

Because this surface runs unscoped, an admin endpoint that takes a customer identifier will act on any customer it is given. The safety that protects the storefront surface is switched off here by design. Endpoints on this surface must validate what they are asked to touch; nothing below them will.

What is under it

Content and configuration

Things the business changes

  • cms — content blocks and their versions
  • settings — the live setting groups
  • locations — pickup and branch locations
  • promotions, bonus-product-promotions
  • catalogue/products, /brands, /categories
People and access

Who can do what

  • customer — customer records and lookup
  • users — provisioning, invites, roles
  • sessions — active sessions
  • api-tokens — public API credentials
Operations

Running the thing

  • queue — inspect and replay async work
  • background-tasks — the engines that drain it
  • caching — statistics, and clear
  • notifications — email templates

That third group is the one worth knowing exists. When an order has not reached the ERP, or a welcome email has not arrived, the queue screen is where you find out why and re-run it — no database access, no redeploy. It is the difference between a support ticket taking ten minutes and taking a day.

Configuration is a first-class surface here

Much of what a new implementation needs is data or settings rather than code — email templates, content, locations, promotions, price behaviour, the card provider. The admin surface is where those are changed, live, without a release.

That is also the productisation strategy in miniature: the more a client's differences live behind this surface, the less the second client costs. What is still code today, and what should move, is a question the platform has not finished answering.