Skip to main content
A seller account can read two groups of facts about itself without a second call to the status tool: what state it is in right now, and what its plan includes. Both are opt-in. A get of the seller that names neither returns exactly what it returned before.

Read them

Call get with kind: "seller", no id, and either or both of include: ["operating"] and include: ["entitlements"]:
Both includes belong to the seller account that is reading itself. They are refused on any other kind, on a seller read that names an id, and for a buyer account.

Operating state

status is decided in this order, so the first match wins:
  1. archived when the seller is archived.
  2. paused when buyer intake is on hold.
  3. blocked when it is not paused or archived but a requirement for going live is still open. The status tool lists the open requirements as blockers.
  4. live when none of the above applies.
isPaused and archivedAt are the stored values behind status. They are shown beside it so you can see why the seller is paused or archived. blocked has no stored field of its own: it means a setup requirement is open. This is not the same answer as the go-live state or the setup progress in the readiness read. status says whether buyers can use the seller now.

Entitlements

save_account accepts an operatingMode too. That is the stored choice the seller made. It does not decide what the seller can do, and entitlements.operatingMode does not read it back: this field is what the plan provides. merchandising and operatingMode are two answers from two checks, and you should not infer one from the other. An account whose plan is a listing but which holds a separate Merchandising grant reads merchandising: true with operatingMode: "LISTING_ONLY".

When a read fails

There is no “unknown” value. If Apostra cannot work out operating or entitlements, for example because a plan lookup timed out, the call fails with SERVICE_UNAVAILABLE and returns neither field, so you never act on a guess. Retry the same call.