HomeDocumentationRecipesAPI ReferenceChangelog
Platform OverviewDemoContactImprintLog In
Changelog
Platform OverviewDemoContactImprint
Back to All

Release 2026-05-18

May 20th, 2026

1. Audit Trail – API Keys

All API Key actions (Create, Delete and Edit) are now tracked in the Audit Trail, supporting compliance and full traceability of API Keys.

2. Modal when reaching the Rate Limit

A notification modal will appear when the Rate Limit is reached – similar to the existing session timeout dialogue. This modal provides information about the limit that has been reached, as well as a link to further details . The modal can be closed and the page will then reload automatically.

3. Expiration Date for API Keys

API keys must now be assigned an expiration date and will have a corresponding status (“Active” or “Expired”). The status and expiration date are displayed both in the API key overview and on the user detail pages. When creating a new API key, a validity period must now be selected (7, 30, 60 or 90 days, or unlimited). Existing API keys are not affected by this change.

4. Update OpenAPI Specification

The Billing API specification has been refined with explicit nullable: true definitions for appropriate properties. Please consult the OpenAPI Specification for the semantics of 'nullable', particularly the combined behavior with the required constraint (required vs. optional, nullable vs. non-nullable). Shortly summarized here:

In OpenAPI, the interaction between required and nullable is important:

  • "required" defines whether a property must be present in the payload
  • "nullable: true" allows a value of null to be provided for the property

Furthermore, previously duplicated inline objects (e.g., for MonetaryValue) have been consolidated into a single reusable referenced schema ($ref). This reduces redundancy in the specification and results in a more compact OAS file and a much leaner client-side code base when generating code from our API spec.

These changes enhance clarity and usability for API consumers of the specification without affecting runtime behavior for existing integrations. However, consumers using generated clients or strict null-handling should review and adapt their implementations accordingly from Billing API specification v2-4.23.4 upwards.