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 — what checks currently exist (age restriction, license requirement).
• 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.
• 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.