# Retrieve the onboarding document checklist

`GET /lokta-lms/api/v1/sourcing-partners/{partnerId}/document-checklist`

Returns the onboarding document checklist for a sourcing partner, one row per requirement.

One row per requirement for this partner's type; a DSA and an LSP see different checklists.

Three fields describe requirement and none is redundant. `requirement` (`mandatory | conditional | optional`) and `condition_code` (`has_gstin | is_regulated_entity`, null unless conditional) are the policy, unresolved, enough for a screen to state the rule. `is_required` is the verdict for this partner, already resolved against its own details. Publishing only the verdict leaves a policy view unable to state the rule; publishing only the policy makes every consumer re-derive the verdict, and a re-derivation that drifts is how two screens end up disagreeing about whether a partner is compliant. Do not re-derive it.

`status` is `missing · pending · verified · rejected · expired`. `expired` is derived from `valid_to` against today, never stored: nothing writes to a row on the day a certificate lapses, so a status read straight from storage would report a partner as verified on a document that stopped being valid years ago. Rejection outranks expiry.

The document shown against a requirement is the latest of that type; a partner who re-submits after a rejection or an expiry must not still read as rejected or expired.

A document of a type this partner's checklist never asks for is real and is not hidden; it appears under `/documents`, which answers "what do we hold" rather than "what is needed".

## Parameters
- `partnerId` (path, string, required): Opaque partner id, spr_…

## Responses
- `default`: default response

## Example request (cURL)
```bash
curl -X GET \
  'https://default.lokta.tech/lokta-lms/api/v1/sourcing-partners/{partnerId}/document-checklist' \
  -u '{username}:{password}' \
  -H 'Tenant-Identifier: default'
```

Interactive: https://developer.lokta.ai/reference#operation/checklist