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 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 asadmin
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.
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
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}/
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, omittingnotifications,
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.
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.