get of the seller that
names neither returns exactly what it returned before.
Read them
Callget with kind: "seller", no id, and either or both of include: ["operating"] and
include: ["entitlements"]:
id, and for a buyer account.
Operating state
status is decided in this order, so the first match wins:
archivedwhen the seller is archived.pausedwhen buyer intake is on hold.blockedwhen it is not paused or archived but a requirement for going live is still open. The status tool lists the open requirements asblockers.livewhen 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 outoperating 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.
Related
- Sellers on the V3 tool surface lists every
getkind and include a seller account reads. - Reading your agent’s webhook results shows another opt-in
includeread onget.