> ## Documentation Index > Fetch the complete documentation index at: https://spreecommerce.org/docs/llms.txt > Use this file to discover all available pages before exploring further. # Get onboarding checklist > What this marketplace asks of the seller before it will admit them. Singular: the checklist is always the acting seller's. Every answer is computed server-side by the same evaluator the operator's own view uses, so the panel and the operator can never show different progress. `progress` counts optional requirements too — it is how far along the checklist is, not how close to approval. Read `blocking` on each requirement for that. Each requirement's `id` is what a submission is posted against. A marketplace that asks for nothing returns an empty list, which is a complete answer rather than a missing one. ## OpenAPI ````yaml /api-reference/seller.yaml get /api/v3/seller/onboarding openapi: 3.0.3 info: title: Seller API contact: name: Spree Commerce url: https://spreecommerce.org email: hello@spreecommerce.org description: | Spree Seller API v3 - the marketplace seller panel, where a seller runs their own shop inside someone else's marketplace. This is a branch of its own, not a narrowing of the Admin API. Every endpoint is scoped server-side to the seller the request acts as, which is what makes cross-seller access impossible by construction rather than by rule. Sellers never call the Admin API. ## Authentication Sign in at `POST /api/v3/seller/auth/login` and send the returned JWT as `Authorization: Bearer `. The token carries a `seller_api` audience — a token minted for the storefront or the back office is not accepted here, and vice versa. There is deliberately **no secret API key** for this branch: a credential that could act as a seller without a seller signing in is exactly what the separate audience exists to prevent. ### Choosing a seller A user may run more than one seller. Login returns the list; send the chosen seller's ID in the `X-Spree-Seller-Id` header on every authenticated request. The store is derived from the seller — never sent — so no header can widen what a seller reaches. A request that names no seller the caller belongs to is rejected with `403`. ## Response Format All responses are JSON. List endpoints return paginated responses with `data` and `meta` keys. ## Error Handling Errors return a consistent format: ```json { "error": { "code": "validation_error", "message": "Validation failed", "details": { "name": ["can't be blank"] } } } ``` version: v3 servers: - url: http://{defaultHost} variables: defaultHost: default: localhost:3000 security: [] tags: - name: Authentication description: Seller sign-in, token refresh, logout, and invitation acceptance - name: Account description: The signed-in user, the sellers they may act for, and what they may do - name: Countries description: Country and state reference data for the panel's address forms - name: Delivery Methods description: >- The seller's own ways to ship, and the marketplace methods shared with them - name: Delivery Profiles description: >- The marketplace's delivery vocabulary — what kind of goods a product is, which decides how it ships - name: Delivery Zones description: >- The marketplace's destinations, for narrowing where a seller's own method ships - name: Onboarding description: >- The marketplace checklist a seller completes before admission, and what they submit against it - name: Policies description: The seller's own legal documents, as the marketplace asks them to publish - name: Product Types description: The types a seller may list a product against, and what each adds - name: Products description: The seller's own catalog - name: Profile description: >- The seller's own record — presentation, contact details, addresses, and tax registration - name: Stock Locations description: Where the seller keeps stock, and so where their returns are sent - name: Team description: Who runs this seller, and the invitations nobody has accepted yet - name: Uploads description: Presigned direct uploads for the documents onboarding asks for paths: /api/v3/seller/onboarding: get: tags: - Onboarding summary: Get onboarding checklist description: | What this marketplace asks of the seller before it will admit them. Singular: the checklist is always the acting seller's. Every answer is computed server-side by the same evaluator the operator's own view uses, so the panel and the operator can never show different progress. `progress` counts optional requirements too — it is how far along the checklist is, not how close to approval. Read `blocking` on each requirement for that. Each requirement's `id` is what a submission is posted against. A marketplace that asks for nothing returns an empty list, which is a complete answer rather than a missing one. parameters: - name: X-Spree-Seller-Id in: header required: true schema: type: string responses: '200': description: checklist returned content: application/json: example: status: approved progress: done: 0 total: 0 requirements: [] schema: $ref: '#/components/schemas/SellerOnboardingResponse' '403': description: no seller named, or not a member of it content: application/json: example: error: code: access_denied message: You do not have access to this seller. schema: $ref: '#/components/schemas/ErrorResponse' security: - bearer_auth: [] components: schemas: SellerOnboardingResponse: type: object description: What the marketplace asks of this seller before it will admit them properties: status: type: string example: onboarding description: The seller's lifecycle status progress: $ref: '#/components/schemas/OnboardingProgress' requirements: type: array items: $ref: '#/components/schemas/RequirementStatus' required: - status - progress - requirements ErrorResponse: type: object properties: error: type: object properties: code: type: string example: record_not_found message: type: string example: Record not found details: type: object description: Field-specific validation errors nullable: true example: name: - is too short - is required email: - is invalid required: - code - message required: - error example: error: code: validation_error message: Validation failed details: name: - is too short email: - is invalid OnboardingProgress: type: object description: | How far along the checklist is — not how close to approval, since optional requirements count towards it too. Deliberately just the two counts. A percentage is arithmetic over them, which a client can do and which would otherwise be a second definition of the same fact. properties: done: type: integer example: 3 total: type: integer example: 5 required: - done - total RequirementStatus: type: object properties: id: type: string kind: type: string description: >- Requirement kind. Built-in: accept_terms, complete_profile, billing_address, returns_address, delivery_method, package_type, minimum_products, payout_account, required_custom_fields, policy, attestation, operator_review, document. Extensions may register more. name: type: string description: type: string nullable: true required: type: boolean position: type: number status: type: string enum: - complete - incomplete - pending - rejected action_url: type: string nullable: true blocker: type: object nullable: true blocking: type: boolean accepts_submissions: type: boolean requires_file: type: boolean accepted_content_types: type: array items: type: string required_policy_name: type: string nullable: true terms_html: type: string nullable: true submission: $ref: '#/components/schemas/RequirementSubmission' custom_fields: type: array items: $ref: '#/components/schemas/RequirementCustomField' required: - id - kind - name - description - required - position - status - action_url - blocker - blocking - accepts_submissions - requires_file - accepted_content_types - required_policy_name - terms_html x-typelizer: true RequirementSubmission: type: object properties: id: type: string status: anyOf: - type: string enum: - pending - accepted - rejected - waived - type: string description: The values listed are the built-in ones; extensions may add more. note: type: string nullable: true review_note: type: string nullable: true reference: type: string nullable: true reviewed_at: type: string nullable: true created_at: type: string updated_at: type: string file_url: type: string nullable: true file_name: type: string nullable: true required: - id - status - note - review_note - reference - reviewed_at - created_at - updated_at - file_url - file_name x-typelizer: true RequirementCustomField: type: object properties: id: type: string key: type: string label: type: string field_type: type: string enum: - short_text - long_text - rich_text - number - boolean - json value: type: object required: - id - key - label - field_type - value x-typelizer: true securitySchemes: bearer_auth: type: http scheme: bearer bearerFormat: JWT description: JWT token for an authenticated seller session (`seller_api` audience) ````