> ## 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. # Release Notes > The paywise Partner API is regularly updated with new and improved features. This page documents a frozen v1 API. It receives only critical correctness or security corrections. For new integrations, use the [current API](/api-docs/overview) and follow the linked [migration guide](/api-docs/legacy/overview#migration-guides). ## October 2026 ### October 02 * **Email notification channels are validated before writes (DEVPW-3253).** On [Create User](/api-docs/legacy/partner/users/create-user), [Create Company](/api-docs/legacy/partner/companies/create-company), and [Update Company](/api-docs/legacy/partner/companies/update-company), a channel with `channel_type: "EMAIL"` must have a syntactically valid email address in `value`, with at most 128 characters. Invalid addresses and longer values now return `400 Bad Request` with an error under `notification_channels[].value` before any data is created or updated. Previously malformed addresses could be saved and fail to receive notifications; overlong values could produce a 500. Accepted channel values retain their submitted case, and other channel types are unaffected. Integrations forwarding user input must handle a 400 where they previously received a success response. See [Notification channels](/api-docs/legacy/partner/onboarding-api-only#notification-channels). The current Partner API already validates these values and is unchanged. ### October 01 * The `country` field of company addresses now accepts **`XK`** (Kosovo), in requests and in responses. Kosovo has no official ISO 3166-1 code; `XK` is the user-assigned code in common use (for example in IBANs). Previously a company in Kosovo had to be created with a neighbouring country's code. * No existing value was removed or renamed. If your integration validates responses against a fixed list of country codes, add `XK`. ## September 2026 ### September 25 * **Legal representatives accept `aufsichtsrat`.** The legal-representative `type` enum now contains `aufsichtsrat` (supervisory board), which the [legal-form table](/api-docs/legacy/partner/entities) already required for a European company (SE): its representatives are `vorstand` and `aufsichtsrat`. The value is accepted by [Create Company](/api-docs/legacy/partner/companies/create-company) and [Update Company](/api-docs/legacy/partner/companies/update-company) and returned on reads. Clients that validate the enum strictly must accept the new value. * **Partner keys act as a member of your own company.** A Partner v1 request acts in the name of a member of the company your Partner belongs to: the key's creator while they are an active member there, otherwise another active member, administrators first — never a paywise staff account and never a member of a company you manage. It now answers `401` in two cases that used to succeed: your Partner has no own company in paywise and the key's creator is no longer active, or your company has no active member the key can act as. Keys keep working when their creator leaves as long as another active member remains. The current Partner API is not affected. Contact paywise support if your Partner has no company assigned. * No other endpoint or field changed. ### September 14 * Company and user notification channels now receive all four default notification types (`REQUESTS_TO_CLIENT`, `STATUS_UPDATE`, `STATEMENTS`, `ADVANCE_REQUESTS`) when `notification_types` is omitted, `null`, or `[]`. Previously these inputs created channels with no subscriptions. The same rule applies to replacement channels in company updates. Nonempty selections keep their existing behavior, including the automatic addition of `ADVANCE_REQUESTS` alongside `STATEMENTS`. Sending an empty type list through the Partner API therefore no longer disables subscriptions; use the paywise portal for that. Explicitly supplied user channels are also linked to the specified company, making them eligible for notification delivery. Existing empty channels are not automatically backfilled. See [Notification channels](/api-docs/legacy/partner/onboarding-api-only#notification-channels). ### September 10 * **Offboarded companies are closed to new users and invitations.** When a client company has been permanently closed (offboarded) on paywise, [Create User](/api-docs/legacy/partner/users/create-user) (`POST /partner/v1/users/`) and [Create User Invite](/api-docs/legacy/partner/userinvites/create-user-invite) (`POST /partner/v1/userinvites/`) return **`400 Bad Request`** with a message explaining that the company is offboarded. Nothing is created in that case: no user, no invite and no `invite_url`. Existing users, invites and companies are not affected, and no request or response field was added or removed. Integrations that create users or invites automatically should treat this 400 like the existing "email already in use" case and stop retrying. ### September 02 * The `email` field of **Create User** (`POST /partner/v1/users/`) is now validated for syntax. A malformed address is rejected with a 400 Status Code and the field-level error `{"email": ["Invalid email address. Please provide a valid address."]}`; no user, membership, notification channel or invitation is created. Previously any string was accepted, which stored an unusable address, silently prevented the invitation email from being delivered, and made every later claim submission for that company fail. If your integration forwards addresses typed by end users, expect a 400 where you previously received a 201. **Create User Invite** (`POST /partner/v1/userinvites/`) was already validated and is unchanged in that respect, but now accepts a slightly wider range of valid addresses (for example an apostrophe in the local part or a non-ASCII domain); addresses accepted before are still accepted. Both endpoints apply the same rule, and the duplicate-address responses are unchanged. Both endpoints also reject addresses longer than 128 characters with the same error: the address is copied into several columns during onboarding, the narrowest of which hold 128 characters, so a longer address previously produced a 500 and left a user that could not be completed. ### September 01 * New notification type **ADVANCE\_REQUESTS** ("Vorschussrechnungen") available in the `notification_types` of a company's notification channels. Channels carrying this type receive advance invoices (e.g. court cost advances) by email, separately from periodic statements. All existing channels with the `STATEMENTS` type were automatically extended with the new type, so nothing changes for current recipients. Integrations do not need to change either: when you submit `notification_types` containing `STATEMENTS` without `ADVANCE_REQUESTS`, the API adds `ADVANCE_REQUESTS` automatically (you will see it in responses). From now on the two types can be configured independently in the paywise portal: for example, a company can route advance invoices to its accounts payable department while statements keep going to receivables management. A company without any `ADVANCE_REQUESTS` channel keeps receiving advance invoices via its `STATEMENTS` channels as before. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.