> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apostra.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reading your seller's setup checklist and go-live state

> How a seller account reads its setup checklist, go-live verdict, starter-brief coverage, product count and source-health diagnoses in one call.

A seller account can read its whole setup picture in one call: the checklist it still has to finish,
whether it is live, how much demand its inventory covers, how many wholesale products it has, and what is
wrong with its sources. It is opt-in. A `get` of the seller that does not ask for it returns exactly what it
returned before.

## Read it

Call `get` with `kind: "seller"`, no `id`, and `include: ["readiness"]`:

```json theme={null}
{
  "readiness": {
    "phase": "crawl",
    "checks": [
      {
        "id": "operator_domain",
        "name": "Seller Account domain",
        "description": "Verify the domain buyers see for your seller account.",
        "status": "missing",
        "isBlocker": true,
        "details": null,
        "action": { "page": "seller_setup" }
      }
    ],
    "goLive": {
      "state": "setup",
      "reasonCode": "setup_incomplete",
      "progress": {
        "required": 5,
        "completed": 3,
        "inProgress": 1,
        "nextStepId": "operator_domain",
        "issues": { "attention": 0, "critical": 0 }
      }
    },
    "demandCoverage": {
      "eligibleCombinations": 12,
      "coveredCombinations": 5,
      "sampleBriefs": []
    },
    "wholesaleProductCount": 7,
    "diagnoses": []
  }
}
```

The include belongs to the seller account that is reading itself. It is refused on any other kind, on a
seller read that names an `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 in `checks` is one setup step.

| Field | Meaning |
| - | - |
| `id` | Stable id of the step, for example `operator_domain`. |
| `name`, `description` | What the step is, in words. |
| `status` | `complete`, `partial`, `missing` or `optional`. `optional` means the step is not required before going live. |
| `isBlocker` | `true` when the step must be complete before the seller can go live. |
| `details` | Evidence for the current status, or `null` when there is none. |
| `action` | Where to resolve the step, or `null` when the step is complete or has no destination. |

`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.

| State | Meaning |
| - | - |
| `setup` | Not live yet, and that is expected. |
| `live` | Live and healthy. |
| `live_attention` | Live, with something worth acting on. Buyers are not stopped. |
| `live_critical` | Live, or paused after going live, and buyers cannot be served as promised. |

`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](/v3/seller-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 with
`SERVICE_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](/v2/setup/v3/tool-reference) lists every `get` kind and include a seller account reads.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.