Introduction
Lexabit is a transaction data platform: it centralizes company intelligence, bank account and transaction data, and client/case management for any team that needs to work with financial activity — Nordic law firms, financial institutions, insolvency practitioners, authorities, and other organisations. An entity permission model built for professional work — multiple clients, multiple cases, controlled access across both — underpins all of it.
The bigger picture: Lexabit is a portfolio of products (account intelligence, entity/ownership intelligence, compliance, monitoring, and detection) that build on each other, so that data from one enriches the next. Fighting financial crime is an important use case — but the platform fits any case where transaction data needs to be retrieved, understood, and acted on. The Products section explains that portfolio and what's available via the API today; this Getting Started section gets you making calls.
The Lexabit API gives you programmatic access to the same capabilities as the Lexabit portal.
What the API offers
The API is organized into seven service areas — the foundation the product portfolio is built on:
| Area | What it covers |
|---|---|
| Company Intelligence | Company search, lookups, financials, ratings, and bank/IBAN utilities |
| Account Tracking | Bank account discovery, consent management, transactions, and counterparts |
| Entity Management | Clients, cases, teams, groups, and projects — the core work entities |
| Product Management | Product catalog, activation, credentials, and subscriptions |
| Access & Permissions | Users, roles, scopes, and effective-permission checks |
| Data Registry | Dataset and dataset-profile management |
| Authentication | Login, registration, password reset, and token management |
Base URL
All requests are made against:
https://api.lexabit.com
If you need to develop or test against upcoming features before they reach production, use the staging environment instead:
https://api.staging.lexabit.com
Staging mirrors the production API surface but runs pre-release code and uses separate data — don't point production integrations at it. Swap only the host; paths, authentication, and everything else in this documentation are identical.
Versioning
Each product area is its own service, versioned independently under the path
/{service}/v1/.... For example: /clients/v1, /company/v1/companies,
/auth/v1/login. There is no single global API version — each service can
advance to v2 on its own timeline without affecting the others.
Next steps
- Quick Start — make your first authenticated request
- API Conventions — the response envelope (
data/meta/error), scoping, pagination, and errors that apply to every endpoint - Authentication Overview — how to obtain and use a bearer token
- API Reference — the full, browsable endpoint reference