You're reading version 2025-01-01, which is not the latest. The latest is 2026-04-01: see this page in 2026-04-01.
Wealth API
The API allows you to collect and aggregate pension and investment data from a variety of companies.
This documentation contains a description of the methods available, examples of requests and responses and details about the returned objects.
Available companies
Check the Catalog to get the full list of companies supported.
A note on data - missing/null data points do not indicate zero/nothing value but should rather be viewed as unknown value.
Service availability
Due to technical issues and planned maintenance the supported companies may be unavailable time to time. Before starting a data collection, it is therefore recommended to first company statuses to obtain a status on which companies that are currently available.
Career statement (PDF)
For fr-info-retraite the wealth data can also include the end user's career statement (relevé de carrière) as a PDF. See FrenchCareerStatement for what it contains and how to download it.
Data collection example
Following is a step-by-step tutorial on how to obtain data through the API:
Check if the company is available using the company API.
If the company is available, start a data collection for a user and use the appropriate loginMethod.
Poll the status of the data collection. Polling interval speeds might vary depending on loginMethod. See CollectionRequest
Collection statuses
Statuses without a version note are returned by every API version. A note such as 2026-04-01+ means the status is only returned by that version and later, and a market list such as ee/lt/lv means only those markets return it.
| Status | Description | Action |
|---|---|---|
RUNNING | Collection process has started. | Keep polling status. |
LOGIN | Authenticating the user and signing in to the company. | Keep polling status. Check if there is any extraInformation included that indicates further actions need to be taken. |
CUSTOMER_ENROLLMENT_CHECK | Checking whether the user is enrolled as a customer with the company before the collection continues. | Keep polling status. |
TWO_FACTOR_PENDING | Waiting for the user to supply a two-factor code, see details here #definition-TwoFactorCode. | Keep polling status. |
TWO_FACTOR_METHOD_SELECTION_TIMEOUT | The user did not choose a two-factor method in time, so the collection was terminated. | Ask the user to retry if they still wish to collect their data. |
CONTACT_FORM_PENDING | The company asks for the user's contact details before it lets the collection continue. The values to provide are listed under the REQUIRED_INPUT_TYPES key in extraInformation, for example EMAIL and MOBILE_PHONE_NUMBER. | Ask the user for the requested contact details, or use ones you already have, and submit them to the supplement-info endpoint as a CollectionInput. If no input arrives within a few minutes, the collection ends with CONTACT_FORM. |
COLLECTION_INPUT_PENDING | The collection needs additional input from the user before it can continue. The values to ask for are listed under the REQUIRED_INPUT_TYPES key in extraInformation. | Ask the user for the requested values and submit them to the supplement-info endpoint as a CollectionInput (the collection will time out if no input is provided). |
COLLECTION_INPUT_TIMEOUT | The additional input requested by COLLECTION_INPUT_PENDING was not supplied in time, so the collection was terminated. | Ask the user to retry if they still wish to collect their data. |
WAITING_FOR_USER_ACTION | User action is needed in order for authentication to continue, e.g. signing in an authenticator app such as BankID. | Check if there is any extraInformation included that indicates further actions need to be taken. If no extraInformation is provided with this status inform the user to open their authenticator app and sign. |
COLLECTING | Collection of data has started. | Keep polling status. |
COMPLETED | Collection process has finished and data was successfully collected. | Fetch the collected data from this API's data endpoint, listed under Routes in the sidebar. |
COMPLETED_PARTIAL | Collection process has finished but not all data was collected. Might be caused by unexpected timeouts or other temporary issues. | Try again or proceed as if COMPLETED. Perhaps prompt the user with what was found and ask if a new collection is wanted. |
COMPLETED_EMPTY | Collection process has finished but no data was found. A reason for this could be that the user is not a client with the company we are collecting from. Or did not have any of the products that was searched for. | Explain to the user that they do not have any products at the company they are collecting from. |
FAILED | Collection process failed. Could be caused by unexpected timeouts, site being down or other temporary issues. | Explain to the user that there was an unexpected error during the collection and ask if they want to redo the collection. |
FAILED_PDF_PARSE | Collection failed because of an error when trying to parse an insurance from a PDF file passed in using the PDF_UPLOAD login method. | Ask the user to try again with a different PDF file or change selected line of business. Explain that the PDF file should be a document containing specific terms for their insurance. |
FAILED_PDF_USER_INPUT | Collection failed because an unsupported PDF file was passed in using the PDF_UPLOAD login method. | Ask the user to try again with a different PDF file or change selected line of business. Explain that the PDF file should be a document containing specific terms for their insurance. |
INCORRECT_CREDENTIALS | The user has entered incorrect login credentials. | Explain to the user that credentials seem to be incorrect and ask to re-enter credentials. As a courtesy you can explain that the user may be blocked from services after too many retries. |
INCORRECT_TWO_FACTOR_CODE | The user has entered an incorrect two-factor code. | Explain to the user that the code seems to be incorrect and ask them to retry. As a courtesy you can explain that the user may be blocked from services after too many retries. |
AUTHENTICATION_TIMEOUT | Authentication timed out while waiting for the user to authenticate. | Ask the user to retry if they still wish to collect their data. |
AUTHENTICATION_CANCELLED | Authentication was cancelled by the user. | Ask the user to retry if they still wish to collect their data. |
AUTHENTICATION_CONFLICT | Authentication was cancelled due to multiple ongoing authentication sessions. | Depending on loginMethod, explain to the user what may have caused conflicting authentication sessions and ask them to retry. |
AUTHENTICATION_MISMATCH | The person initiating the collection is not the person that has authenticated. | Explain to the user that there seems to be a mismatch between the user and the one who signed with BankID. See section below for further explanation on this status code. |
AUTHENTICATION_ERROR2026-04-01+ | Authentication failed for a reason other than incorrect credentials, for example a rejected consent or an error raised by the company during sign-in. | Explain to the user that they could not be signed in and ask if they want to retry. |
LOGIN_METHOD_NOT_APPLICABLE2026-04-01+ | The requested loginMethod cannot be used for this company. | Read the supported methods from the company availability response and start a new collection with one of those. |
REJECTED_INCORRECT_LOGIN_METHOD2025-01-01 only · ee/lt/lv | The collection was rejected because the requested loginMethod is not supported by the company. From 2026-04-01 this case is reported as LOGIN_METHOD_NOT_APPLICABLE. | Read the supported methods from the company availability response and start a new collection with one of those. |
ACCOUNT_TEMPORARILY_LOCKED | The user's access to the company has been temporarily blocked. For example, this could happen if the user tries to authenticate multiple times with incorrect login credentials. | Explain to the user that they cannot access their account right now and suggest to try again later. The exact time to wait differs between companies but a guideline would be to try again after 15 minutes. |
KYC_FORM | When logging in we have been prompted with a KYC form with AML related questions blocking us from proceeding with the collection. This has to be filled in manually by the user by logging in to the company through the company app or website. Then the user can initiate a new collection. | Explain to the user that the collection required information to be submitted by the user. Say that it may resolve by the user themselves signing in to their account and answer a form. |
CONTACT_FORM | When logging in we have been prompted with a form asking for user contact details blocking us from proceeding the collection. This has to be filled in by the user by manually logging in to the company through the native app or website. Then the user can initiate a new collection. This status is also displayed if the CONTACT_FORM_PENDING times out. | Same as KYC_FORM. |
CUSTOMER_ENROLLMENT_REQUIRED | The user needs to sign up as a customer with the company before we can log in and collect data from them. This happens mostly for Handelsbanken, Nordea and Futur where a user could have e.g. an occupational pension without actually being customers at the company. | Either proceed as COMPLETED_EMPTY or explain to the user that we could not access any account. |
THIRD_PARTY_ERROR | The collection failed due to an error on the company's end. Underlying cause could be unexpected timeouts or errors. | Explain to the user that the company was unavailable to collect data from but that they can retry the collection. |
Authentication
Calls from your server authenticate with an API key, sent in the Authorization-token header. Send Insurely-Version on every request too (see API versioning).
| Header | Header Value |
|---|---|
| Authorization-token | Your API key |
| Insurely-Version | The API version you integrate against, for example 2026-04-01 |
Getting an API key
If your organisation uses the Insurely Hub, a customer admin can create and delete API keys there: open your client's settings and go to the API & Credentials tab. You can have several keys at once, so to rotate a key, create a new one, deploy it, then delete the old one. Without Hub access, email support@insurely.com and we'll provide one.
Keep API keys on your server. Never put them in a web page or mobile app.
Environments
| Environment | Base URL |
|---|---|
| Production | https://api.insurely.com |
| Test | https://api.test.insurely.com |
Use the API key issued for the environment you call.
IP allowlist
Requests authenticated with an API key are only accepted from the IP addresses registered for your client. Send your servers' outbound IP addresses to support@insurely.com for each environment. A request from an address that isn't registered gets 401 with the message Authentication failed, the same response as an invalid key, so check both when you see it.
Demo companies
Demo companies let you run a full collection without a real login; this API's Demo companies page lists them and the test personal numbers. If one is missing from your GET /companies/availability response, ask us at support@insurely.com to enable it for your client.
API Versioning
Every request should send the Insurely-Version header with the date of the version you integrate against, such as 2026-04-01. The version these pages describe is shown in the API picker at the top of the sidebar.
If the header is missing, or names a version older than your client's minimum version, the API uses your client's minimum version instead. That is usually an older version than the one you are reading about, with different endpoints and fields, so always send the header.
| Header | Header Value |
|---|---|
| Insurely-Version | The version of the API, as YYYY-MM-DD |
Mutual TLS (mTLS)
Our APIs have support for mTLS. These are the steps needed to enable mTLS for your client.
Create two private keys and two Certificate Signing Requests (CSR), one for test and one for production, and send them to support@insurely.com. We will sign and send the certificates back.
genrsa -out my_test_client.key 2048
openssl req -new -key my_test_client.key -out my_test_client.csr
openssl genrsa -out my_prod_client.key 2048
openssl req -new -key my_prod_client.key -out my_prod_client.csrVerify your received certificates
curl --key my_test_client.key --cert my_test_client.pem 'https://mtls.api.test.insurely.com/health'
curl --key my_prod_client.key --cert my_prod_client.pem 'https://mtls.api.insurely.com/health'You should get the same response for both requests:
{ "status": "healthy" }- To enforce mTLS - prefix all urls with the mtls subdomain as shown in verification examples above.