get of the seller that does not ask for it returns exactly what it
returned before.
Read it
Callget with kind: "seller", no id, and include: ["readiness"]:
id, and for a buyer account. It is the largest seller include, so ask for it only
when you need the checklist. To see only what is blocking the account, call the status tool.
Phase
phase is where the seller is in setup: crawl, walk or run. pass_through is accepted for older
records and is not normally returned.
Checks
Each entry inchecks is one setup step.
action has the same shape as an entry in the status tool’s nextActions: a tool to call, a page to open
for a step a model must not drive (a credential or an access grant), a url, and the arguments to pass.
Go-live
goLive.state is one of setup, live, live_attention or live_critical. reasonCode says why it
landed there.
progress counts the go-live steps: required steps the seller is held to, how many are completed, how many
open ones are inProgress, and the nextStepId (a check id) to take next. nextStepId is null once the
seller is live or nothing is left. issues counts the open problems behind the live states. Both are 0
while the state is setup.
This is not the same answer as whether buyers can use the seller right now, which the status tool reports as
state. The go-live state adds setup progress and post-live health to it.
Demand coverage and products
demandCoverage says how many starter briefs the seller’s inventory could cover. eligibleCombinations is
how many category, market and channel combinations the seller’s profile makes it eligible for, and
coveredCombinations is how many of them its products cover. sampleBriefs shows up to four of them, each with
a category, market, channel, a status of covered or needs_inventory, and a rationale. They are
derived from the seller’s own profile and inventory. They carry no buyer data.
wholesaleProductCount is the number of wholesale products the seller has authored across its inventory
sources. It is null when no source reports a count, which is different from 0.
Diagnoses
diagnoses lists what is wrong with the seller’s inventory sources. Each entry has a diagnosisId,
sourceName, failureMode, owner, severity, a one-sentence summary, optional detail and docsAnchor,
and the action that fixes it. Only an entry with owner: "seller" is something the seller has to do. Its
severity is blocking when it stops selling, attention when it degrades selling, and advisory when it
will only matter later.
The list is capped at 10 entries, most severe first (blocking, then attention, then advisory, and in the
order Apostra found them within a severity). A seller with more than 10 problems sees the 10 that matter most.
Read the full per-source list with get for kind: "inventory_source" and include: ["diagnostics"], or open
the source diagnostics page.
When a read fails
There is no “unknown” value. If Apostra cannot work out any part of the readiness, the call fails withSERVICE_UNAVAILABLE and returns none of it, so you never act on a partial checklist. Retry the same call.
Related
- Sellers on the V3 tool surface lists every
getkind and include a seller account reads.