Skip to main content

Entity Conditions Service (ECS)

ECS lets conditions be attached to items and checked automatically at checkout — for example, an age restriction on alcohol, or a license requirement on a controlled product. If you're a B2B tenant, it's also what enforces your projects' purchasing rules, so a purchase made against a project only goes through if it satisfies that project's restrictions.

You'll use ECS in two ways:

  • As a shopper-facing check. Some conditions are defined by the platform (for example, legally required age restrictions) and apply automatically — you don't need to do anything for these to work.
  • As something you configure. You can define your own conditions for your own catalog, and — if you're a B2B tenant — your projects carry their own restrictions on what can be bought against them.

Concepts​

  • Entity condition — what a condition is, and the difference between a platform-owned one and one of your own.
  • Rules and supported checks — the checks that exist:
    • age restriction
    • license requirement, including a minimum license level
  • Project restrictions — purchasing rules attached to a B2B project.
  • Decisions and outcomes — what checkout actually sees back when a check runs, and how multiple checks combine on one item.

What to expect​

  • Changes take effect within a few minutes, not instantly. After you add, change, or remove a condition, there's a short delay before checkout picks it up — usually well under ten minutes, often faster. Plan around a short delay rather than expecting an immediate effect.
  • An item that references a condition checkout doesn't recognize is held back, not let through. If one of an item's condition ids doesn't exist, is disabled, or hasn't reached checkout yet, that check soft-denies the item instead of being skipped — see Entity condition.
  • Checkout keeps working even if ECS is briefly unreachable. The check that runs at scan time doesn't depend on ECS being reachable in that moment.
  • Project restrictions are checked live, not on the same delay. Unlike entity conditions, a project's restrictions are looked up at the moment of purchase (briefly cached, for well under a minute) rather than on the multi-minute refresh cycle above — a change to a project's restrictions takes effect faster than a change to an entity condition does.
  • You can try before you commit. Both entity conditions and project restrictions have a preview endpoint that runs the same check against a single item without a real transaction — see the API reference.
  • A misspelled restriction type won't warn you — it'll just do nothing. See Project restrictions for the exact types; double check the spelling when setting one up, since there's no validation to catch a typo.

API​

See the API reference for the endpoints used to list, create, and preview your own entity conditions, and to preview a project restriction outcome before relying on it at checkout.

Integration​

Building or running the evaluation sidecar yourself? See the integration guide for local setup and CI/CD.