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

# Readiness and access

> Understand when a company can submit cases and what happens when a partner connection ends.

A connected company can submit cases as soon as its required company and
administrator data are complete. The company response tells you whether it
is ready and whether your partner has Case Management API access:

| Field | Meaning |
| - | - |
| `case_submission_readiness.ready` | The required company and administrator data are complete. |
| `case_access` | Your partner can currently use the Case Management API for this company (`available` or `unavailable`). |

Both must permit submission. The case itself must also pass validation.
You can prepare drafts while company data are still incomplete.

## How onboarding reaches readiness

paywise enables the onboarding options agreed during your partner setup:

* **API-only onboarding:** you provide the company and administrator data.
  Provisional access allows submission while the invited administrator still
  needs to complete account setup and confirm the connection.
* **Hosted onboarding:** the client provides the required details and
  authorizes your partner in the paywise flow.
* **Existing company:** the client authorizes the connection to their company.
  Its existing data determine whether it is already ready.

Use the returned readiness `issues` to identify missing or invalid data.
Follow [Resolve readiness](/api-docs/partner-api/workflows/resolve-readiness)
for corrections. Account activation alone is not the submission requirement.

Company data you send is validated before readiness is evaluated
(`400 validation_error` with a field path and code):

* `address.country` is a two-letter ISO 3166-1 code string: a non-string
  value is `invalid`, `""` is `blank`, and `null` is `null`.
* `address.postal_code` takes ASCII digits only; a visually identical
  non-ASCII digit is `invalid` (`Use ASCII digits.`) before the country
  pattern is consulted.
* `legal_representatives[].type` takes the English role codes
  `managing_director`, `director`, `board_member`, `chairperson`,
  `general_partner`, `shareholder`, `owner`, `partner`, `supervisory_board`,
  and `other`; the German codes of the legacy Partner API are
  `invalid_choice`.
* `GET /partner/v2/legal-forms/` lists in `representative_requirements` the
  roles a company with that legal form must name before it is ready for case
  submission. Readiness and the write validation apply the same rule, so a
  company that names exactly the listed roles is ready. A legal form with
  requirements accepts only its listed roles; a role it does not accept is
  `invalid_for_legal_form` on `legal_representatives`, with a message that
  names the codes, for example
  `Legal form kg accepts only representatives of type general_partner; not allowed: owner.`
  A legal form without requirements accepts any role. A missing role is
  reported as `company.legal_representatives` with code
  `representative_required`, for example
  `A legal representative with type "supervisory_board" is required.`
* The Partner catalog describes company representatives; `GET /v2/legal-forms/`
  on the Case Management API describes debtor representatives, and the two can
  differ. An SE (`se`) lists `board_member` and `supervisory_board` for a
  company but only `board_member` for a debtor. Use the Partner catalog for
  companies and the Case catalog for debtors.
* `GET /partner/v2/legal-forms/` carries a strong `ETag`; send it back as
  `If-None-Match` to receive `304 Not Modified` while the catalog is
  unchanged.
* `GET /partner/v2/companies/?ordering=` accepts the documented fields only;
  an unknown term is `400` on `ordering` with code `invalid_parameter`.
* `PUT` is not offered: on a company it is `405` with the hint to use
  `PATCH`, on a collection route it is a plain `405`.

## Disconnecting and reconnecting

The client or your partner can end the connection. Disconnection revokes all
partner access to the company, its users, cases, and updates. A final
`company.access.revoked` notification tells you the connection ended.

Unsubmitted drafts created by your partner are deleted. Submitted cases,
company-created drafts, and the client's own paywise access remain intact.

To reconnect, the client follows the same connection flow and approves access
again. The company keeps its identity and records. Deleted drafts and events
missed during disconnection are not restored; fetch current data before
resuming work.

Follow [Release a company](/api-docs/partner-api/workflows/release-a-company)
to disconnect through the API and [Handle access changes](/api-docs/partner-api/workflows/handle-access-changes)
to keep your integration in sync.

See [GET `/partner/v2/companies/{id}/`](/api-docs/partner-api/reference/companies/get-a-managed-company)
for the readiness and access fields.


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