Release Notes

September 2026

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.

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.