API Documentation

Easy, fast and scalable

wealthAPI follows an API-first approach: every feature of our finance manager and multibanking solution is available through a RESTful API.

REST
JSON
OpenAPI
JWT Bearer
MCP

# Request funds by ISIN
curl "https://sandbox.wealthapi.eu/api/v1/funds?isin=DE0009848119&isin=LU0323578657" \
  -H "Authorization: Bearer <auth_token>"

# Auth tokens expire after 1 hour - renew via refreshToken

200 OK Content-Type: application/json

Technical documentation

API references

Each API comes with its own OpenAPI documentation. Tutorials on our Confluence developer page take you from creating a user to importing your first bank connection, and cover user management and keeping credentials secure.

Changelog

Take a look at the changes we've made to our API over the last week.

API change log

Regulatory compliance for account information services

PSD2 services are provided through partners. Depending on your use case, PSD2 (ZAG in Germany) may apply to you as a customer.

Getting started

How to start using the API

The API follows a mandator-based approach that separates user data by domain - usually one mandator per SaaS customer.

Create a free Sandbox account
Sign up via the developer dashboard and get access to all asset data, including banking and investment insights.
Use your mandator credentials
Your mandator keeps your users' data separate. Users are bound to the mandator they were created in.
Build against Sandbox, go live on Production
Develop and test in the Sandbox environment, then switch the host to Production.

General

API conventions

wealthAPI is a RESTful interface for programmatic access to our system. These conventions apply across all endpoints.

URI information

URI format

https://{environment}/api/{version}/{resource}{additional-parameters}

# Example
https://sandbox.wealthapi.eu/api/v1/funds?isin=DE0009848119&isin=LU0323578657

Versions are whole numbers. They are incremented for breaking changes or major functional upgrades.

URI parameters

Each endpoint defines whether a parameter may occur once or repeatedly. Repeatable parameters accept both array and plain syntax:

# Array syntax
?id[]=1&id[]=2&id[]=3

# Plain syntax
?id=1&id=2&id=3

Request types

Method	Purpose	Parameters & body
GET	Retrieve data	Parameters in the URL, no body
POST	Create data	JSON body, usually no query parameters
PUT	Modify existing data	Entity ID in the path, JSON body
DELETE	Delete or invalidate data	ID in the path, no body

Using the wrong method returns an "invalid request type" error. The API documentation states the required method for every endpoint.

Status codes

200 · 202 Success Any other code: error

The possible status codes for each operation are listed in the API documentation.

Accept & content types

Requests must be sent as application/json. Responses are JSON by default - a few methods return PDF documents.

Response format

Unless stated otherwise, responses are JSON objects or arrays. Many endpoints support pagination; their responses then include the pagination settings. See the API documentation for each response schema.

Date & time format

# Requests - format defined per endpoint, typically
yyyy-MM-dd

# Responses
ISO 8601

Authentication

The API is designed to be used directly from frontend code, for example JavaScript in the browser or in mobile apps. A successful login returns an auth token and a refresh token.

Authorization: Bearer auth_token

# Auth token expires after 1 hour
# Renew it by sending the refresh token to refreshToken

Tokens are JWTs, so there is no server-side logout - to log out, delete the token on the client. The login and refreshToken operations are documented in the Sandbox API reference.

Mandator-level authentication

Some operations act on mandator level rather than user level - for example support requests for users who can no longer access their account. Send the mandator credentials as headers:

X-Mandator-Client-Id: <client_id>
X-Mandator-Client-Secret: <client_secret>

User creation and mandators

Public ID

For non-sensitive mandator operations such as creating users. Always provide it when creating users so you keep full access to them later. Users created this way must confirm their email address.

Private ID

For sensitive operations such as creating users without email confirmation. Keep it secret and safe: unconfirmed email addresses are a security risk.

A user is bound to a mandator at creation. Switching mandators is not possible.

Authorization & roles

Role	Grants
ROLE_USER	Standard role for regular users and the default. Required by most endpoints.
ROLE_STATS	View aggregated statistics.
ROLE_USER_MANAGEMENT	Change user data.
ROLE_ROLE_MANAGEMENT	Assign and remove roles for users in the administrator's mandator.
ROLE_SUBSCRIPTION_MANAGEMENT	Manage subscriptions for the administrator's mandator.
ROLE_BI	Read and write aggregated statistics and business analytics data.
ROLE_ACCOUNTING	Modify subscriptions and manage billing cycles.
ROLE_B2B_ADMIN	Create and update business-to-business users (feature for bloggers).
ROLE_APPLICATION_PROPERTY_ADMIN	Create and update application properties.
ROLE_INSURANCE_ADMIN	Create and update insurance master data. Internal wealthAPI developers only.

Administrative roles only apply to users within the administrator's own mandator.

Assigning roles

New users receive ROLE_USER by default. Users with ROLE_ROLE_MANAGEMENT assign further roles via /api/v1/roles.

Anonymous access

Some endpoints can be called without authentication. They are marked in the API documentation with:

x-roles: IS_AUTHENTICATED_ANONYMOUSLY