Docs: Core concepts

Five objects carry almost all the meaning in Omnislice. Once these are clear, most of the platform is guessable.

Organisation

Your company. It owns billing, members, roles and every project underneath. Agencies and operators usually keep one organisation and many projects; a single brand keeps one of each.

Members belong to the organisation, and their access is granted per project. Somebody who runs marketing for one brand does not automatically see another brand's orders.

Project

One commercial operation: a brand, a market, or a client. A project owns its own catalog, channels, customers, orders and content, and it is the boundary almost every API call is scoped to.

Note

Splitting by market (acme-eu, acme-uk) is the right call when catalogs, tax treatment or currencies genuinely differ. If they mostly overlap, one project with several channels is far less work.

Products, variants, options, media, categories and prices. The catalog is channel-agnostic on purpose: a product is a thing you sell, not a listing on a marketplace. Listings are derived per channel through mapping.

That separation is what makes a price change one edit instead of five, and it is what stops a marketplace's category taxonomy from becoming your internal one.

Channel

Anywhere a customer can buy: a storefront, a marketplace, a social shop, a POS till, or a B2B portal. A channel has its own:

Mapping — which products are listed and how their fields translate.
Pricing rules — a price list, a markup, or an override per listing.
Availability rules — which locations feed it, and how much buffer it keeps.
Sync direction — per data type, which side is the source of truth.

Channels are additive. Adding the fifth one costs roughly what the second one cost, which is the entire point of the model.

Order

An order is one record no matter which channel it came from, and it keeps a permanent reference to its origin. Fulfilment, payment and returns hang off it.

Because orders are unified, the numbers you report on — units sold, margin, repeat rate — do not need a warehouse job to assemble. They are already in one place.

How they fit together

An organisation contains projects

Billing, members and roles sit at the top.

A project owns a catalog and its channels

The catalog is the source; channels are the projections of it.

Channels produce orders against shared stock

Every channel draws from the same locations, so availability is a fact rather than an estimate.

Orders route to a location and settle through your processor

Routing decides where it ships from; the processor decides how money moves. Neither is hard-coded.

Terms you will see in the API

project_idstringrequired: Scopes nearly every request. Keys are issued per project.
channel_idstring: Present on listings, orders and channel-specific pricing.
variant_idstringrequired: The sellable unit. Stock, price and barcodes hang off variants, not products.
location_idstring: Where stock physically sits, and what routing resolves to.

Next: Products and variants, where the catalog model gets specific.

Core concepts