Release Notes

​

October 2026

​

October 02

• Email notification channels are validated before writes (DEVPW-3253). On Create User, Create Company, and 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. 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 already required for a European company (SE): its representatives are vorstand and aufsichtsrat. The value is accepted by Create Company and 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.

​

September 10

• Offboarded companies are closed to new users and invitations. When a client company has been permanently closed (offboarded) on paywise, Create User (POST /partner/v1/users/) and 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.