Versioning and Release Management

All APIs exposed under Klarna Network Global API Gateway are versioned in unison and share the same version number. Major versions are denoted by /vx/ in the URL path, for example: https://api-global.klarna.com/**v1**/payment/request

Additionally, releases are denoted in integration guidelines and documentation by vx/ry, for example v1/r5 will indicate specifically release 5 of major version 1

Release cycle

To support effective planning and coordination of technical initiatives, Klarna adopts a structured release schedule consisting of no more than two major version updates per year. In addition, minor releases will be delivered on a monthly basis to provide incremental improvements, bug fixes, and minor feature enhancements.

Release of major versions: Klarna is committed to ensure that updates to our APIs are backward-compatible whenever possible, allowing your systems to continue running smoothly as new features are introduced. However, in specific scenarios, breaking changes are needed. These will be implemented under a new API major version.

Examples of breaking changes:

• Removal of ENUM values
• Removal of actions (HTTP Methods)
• Removal of resources/Endpoints
• Structural changes such as object structures updates or parameter renames
• Change in state machine transitions, or introduction of new states

Release of minor changes: A minor release adds backward-compatible changes. These changes should not require modifications on an active integration to continue using the API effectively. Instead, they add new features or enhancements. The following changes are classified as backwards-compatible and an integration of Klarna Payment Services should be capable of handling them:

• Adding new API resources: introduction of new endpoints or resources will not affect existing functionality.
• Adding new optional request parameters: new parameters added to existing API methods will not alter the behavior of existing calls; they will provide additional functionality if you choose to use them.
• Adding new properties to API responses: additional fields in API responses are designed to be ignored by partners who do not expect them, ensuring compatibility with older versions.
• Changing the order of properties: the sequence of properties in API responses may vary, but this will not impact integrations that rely on proper key-based parsing instead of the order of data.
• Adjustments to opaque strings: changes to the format of strings such as IDs.
• Introducing new event types: new events might be added to our webhooks, if they are optional, and do not affect the behavior of the existing integration. Ensure your webhook listeners are prepared to handle atypical event types gracefully, either by logging them for review (recommended) or safely ignoring them.

Service Lifecycle Stage

We use specific lifecycle stages to tag operations and attributes to describe the availability in Klarna Services.

Availability