Skip to main content

Changelog

Notable changes to the Klart API are recorded here, newest first. Each service is versioned independently under /{service}/v1/…; a breaking change to a service means a new major version for that service, not the whole API.

We follow these rules for what's a breaking vs. non-breaking change:

  • Non-breaking (no version bump): adding an endpoint, adding an optional request field, or adding a field to a response. Write clients that ignore unknown response fields so these never affect you.
  • Breaking (new v2 for that service): removing or renaming a field, making an optional field required, or changing a field's type or meaning.

Unreleased​

Base URL is now api.klart.com​

Lexabit has been rebranded to Klart, and the API's canonical host is https://api.klart.com (staging: https://api.staging.klart.com). The platform is the same; only the name and the hostname changed.

api.lexabit.com answers 301 Moved Permanently to the new host, so existing integrations keep working — but change your base URL rather than relying on the redirect. Some HTTP clients drop the Authorization header when following a redirect to a different host, and some downgrade a POST to GET on a 301. Both fail in ways that do not look like a hostname problem.

The documentation host is now docs.klart.com, and the security contact is security@klart.com. Klart is a trading name — the contracting legal entity on your agreement is unchanged.

Invitations can carry more than one role​

POST /entitymanagement/v1/{entityType}/{entityId}/invitations now accepts requested_role_keys (an array, at least one entry), and the invitation record returns requestedRoleKeys.

The singular requested_role_key is deprecated but still accepted, and the record still returns requestedRoleKey — reporting only the first role. A client reading the singular field on a multi-role invitation sees an incomplete picture with no error, so move to the array.

Invitations also accept an optional member_profile (name, first_name, last_name, phone), applied only when the invitation provisions a new user. It is rejected with 422 for member types other than user, rather than being silently dropped.

New: unauthenticated platform config​

GET /platform/v1/config returns the platform's name, logoUrl, logoInverseUrl, faviconUrl, defaultLocale and maintenanceMode with no token, so a client can brand its sign-in screen and detect maintenance before attempting an authenticated call. The payload is a fixed allowlist — see API Conventions.

Unauthorized reads now answer 404, not data​

A security review tightened authorization on dataset profiles, scoring reads, and consent-account listings. Where a caller outside the owning scope previously received data, these now answer 404 not_found — consistent with the long-standing rule that an entity you cannot see is not confirmed to exist.

This can change behaviour for an existing integration that was reading across scopes. If a call that used to succeed starts returning 404, check the X-Scope you are sending against what that token can actually see.

Clearer failures on role assignment​

POST /users/v1/{id}/roles now distinguishes its failures instead of answering generically: 409 conflict when the user already holds the role, and 422 validation_failed for a role key that is not assignable at that entity (it was previously a 500). 403 still covers both a missing members.manage and an attempt to grant a role exceeding your own.

countryCode is the canonical country parameter​

Company search and lookup now name the parameter countryCode. The older country and country_code spellings are still accepted, so nothing breaks.

One genuine fix: GET /accounttracking/v1/banks only ever read countryCode. A request sending country was silently unfiltered and returned banks for every country — our own documentation had this wrong, and the examples are corrected.

Renamed path parameters in the reference​

Two Account Tracking operations renamed their path parameter — accounts/{accountId}/report → accounts/{account}/report, and the single-transaction PDF's {transactionId} → {transaction}. The URL you build is unchanged (same id in the same position); only the parameter's name in the reference and in generated clients differs.

v1 — Initial public release​

The first public release of the Klart API. Product areas available at launch:

  • Authentication — login, registration, token refresh/revoke, password reset.
  • Company Intelligence — company search, lookup, detail subsets (information, financials, rating, shareholders, signatories, …), and bank/IBAN utilities.
  • Account Tracking — PSD2 consent flow, account discovery/tracking, transaction sync, and counterparts.
  • Entity Management — clients, cases, teams, groups, projects, and the shared profile/contact/address/media/invitation sub-resources.
  • Product Management — product catalog, activation, credentials, and subscriptions.
  • Access & Permissions — users, role assignment, and effective-permission checks.
  • Data Registry — datasets and dataset profiles.

All endpoints share the standard response envelope, X-Scope scoping, and error codes documented in the guides.