Core concepts & data model
The mental model behind every endpoint. Knowing it also shows what the platform already provides, so you don't rebuild features that already exist.
The hierarchy
Organization (the retailer / tenant)
└─ Store(s) physical or virtual selling location
└─ Items per-store price & stock for a variant
Catalog (organization-wide)
└─ Product master record (name, brand, category)
└─ Variant a sellable variation (size, pack)
Customer (organization-wide)
└─ Address(es), contacts, tags
Order (per store, per customer)
- Organization — your credential is bound to one. Everything you read or write lives inside it. (Tenant isolation is automatic.)
- Store — a retailer can run many. Price, stock, orders, slots and delivery areas are per store. Catalog (products, brands, categories) is org-wide.
- Product vs Variant vs Item — a common point of confusion:
- Product = the master record. A simple product still has one variant.
- Variant = the thing a shopper actually buys.
- Item = a variant's price and stock in a specific store. You set it via
the Inventory API and read it on a variant's
storeSpecificData.
Your IDs vs Zopping's IDs
Every major entity accepts a clientId (or clientItemId / clientStoreId)
— your own identifier. Set it on create, then look records up by it later. This
means you never have to store Zopping's numeric IDs to map between systems.
It's also how you keep imports idempotent (re-using a clientId updates instead
of duplicating).
What varies by configuration
Two things change the API's behaviour per organization — learn them before you assume an endpoint is missing or a field is absent:
- Extensions — optional platform features (multi-store, pricing tiers, returns, custom metadata…). What's enabled changes the surface and behaviour.
- RBAC grants — your token is granted specific resources/methods. An endpoint existing ≠ your token may call it.
One Platform API, two gateways
It's all one Platform API, reached two ways depending on who's calling:
- Backend gateway (
zopping.com/api) — staff- and partner-authenticated; the full management/operations surface (this portal's focus). - Storefront gateway (
<store-domain>/api) — a public + end-customer subset, buyer-facing (see Build a storefront).
Where to go next
- Authentication · Access & environments
- Responses & errors — the envelope every call returns
- Custom fields & metaData — extend entities without an external store