> ## 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. # Companies and users > Connect client companies, invite their users, and understand what your partner can manage. A company represents your client in paywise. Its company data, users, and cases belong to that company. Your partner connection lets you manage them through the API. Use the company's `id` in API requests. You can also store your own customer identifier in `external_reference` to match it to your records. ## New and existing companies You can onboard a new company or connect one that already uses paywise. To connect an existing company, the client follows your partner link, signs in, selects a company they administer, and approves the connection. Both have the same partner capabilities. You can access all of the connected company's cases, including cases created before the connection or through the paywise UI. A company can have one connected partner at a time. A client can switch partners by explicitly approving the new connection; this ends the previous partner's access. When upgrading a Partner v1 integration, an already managed company keeps its company UUID and existing cases. Read that same company through v2; no new company or connection is required merely because the API version changes. Credentials and current access must still be verified. Follow the [Partner migration guide](/api-docs/partner-api/migrate-from-v1) to resolve company memberships: their UUIDs identify relationships, not the global users or invitations exposed by v1. ## Users and invitations A membership gives a person access to a company with a role such as `admin` or `readonly`. One person can belong to several companies. Invited memberships start as `pending_setup`, including invitations to people who already use paywise. The person accepts by signing in or setting up their account; the membership then becomes `active`. Accepting activates only the membership of the company whose invitation the person opened; other pending invitations for that person stay `pending_setup` until each is accepted. The add and resend responses carry `setup_url` exactly once: the absolute link to the paywise invite page for that pending membership. It is not part of the membership resource on reads and is omitted from idempotent replays; it is `null` when no invite is open. The link leads to password setup only for an account that this add created — or, on a resend or re-add, for that same account while it has never been used. For every account that existed before — with or without a password, signing in through a social or single sign-on provider, or deactivated — the link leads to sign-in instead, so no invitee can set the password of an account someone else provisioned. The response echoes the names you submitted, never the stored profile, until the person accepts. A password-setup link is refused once its account has been signed in to, linked to a social login, or deactivated. A person who can sign in accepts the invitation by signing in, and a resend gives them a sign-in link. An invitee whose account was created through the Partner API and never used — active, never signed in, no password, no social login — can also use **Passwort vergessen** in the paywise portal. The reset link goes only to that address, never to you, and lets the person set a first password, sign in, and accept the invitation. Include an administrator when onboarding a company. A pending administrator can satisfy submission readiness before accepting the invitation. See [Readiness and access](/api-docs/partner-api/concepts/readiness-and-access). You can manage pending invitations through the API. Revoking an active membership requires a capability enabled by paywise, and the last active administrator is protected. Follow [Manage memberships](/api-docs/partner-api/workflows/manage-memberships) for the supported actions. ## Updating company details Company editing follows the rules in the paywise UI. Contact details, address, default claim type, and notification settings remain editable. Identity, tax, and legal-representative details become protected as onboarding and case submission progress. For protected changes, the client must use the process offered in the paywise UI. Payout-account changes after case submission also require that secured process. See [PATCH `/partner/v2/companies/{id}/`](/api-docs/partner-api/reference/companies/update-a-company-patch) for editable fields and validation. ## Notification settings Company notification channels are email addresses that receive paywise mail for that company. For each channel you supply, omitting `notifications`, sending `null`, or sending `[]` enables all default events: `requests_to_client`, `status_updates`, `statements`, and `advance_requests`. An explicit nonempty selection is kept as sent. This applies both when you create the company and when you PATCH it. Omitting the outer `notification_channels` array on PATCH leaves existing channels untouched; sending an empty array clears the company-level channels, subject to the receiver a company needs before submission. See [Readiness and access](/api-docs/partner-api/concepts/readiness-and-access). Users get their own channel for the company when they accept their invitation, with the same defaults. Accepting one invitation does not activate the person's other pending memberships or create channels for those companies. Channels a user already has, and the events they selected, are preserved. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.