Migration guide

Collections are now a top-level resource (from 2025-01-01)

In 2025-01-01 a wealth collection lived under the product namespace: it was created at POST /wealth/collection and read under /wealth/collection/{collectionId}/.... In 2026-04-01 collections become a single shared, top-level resource. A collection is created at POST /collections regardless of product, and the wealth data is read from a product sub-path — /collections/{collectionId}/wealth/data.

Endpoint mapping

2025-01-01 (wealth)2026-04-01
POST /wealth/collectionPOST /collections (shared across products)
GET /wealth/collection/{collectionId}/statusGET /collections/{collectionId}/status
GET /wealth/collection/{collectionId}/dataGET /collections/{collectionId}/wealth/data
GET /wealth/collection/{collectionId}/document/{documentId}GET /collections/{collectionId}/wealth/document/{documentId}
POST /wealth/collection/{collectionId}/supplement-infoPOST /collections/{collectionId}/supplement-info
POST /wealth/collection/{collectionId}/add-contact-form-inputRemoved — supply the contact form values as a CollectionInput to supplement-info
GET /collections — new: list the collections for the authenticated user

GET /companies/availability and GET /companies/supported-products are unchanged.

Typed request parameters

POST /collections replaces the 2025-01-01 request body — a loginMethod plus an input map keyed by uppercase strings, with separate top-level consents and filter arrays — with a single typed parameters array on InitiateCollectionRequest. Each entry carries a type discriminator and its own named, lower-camelCase fields.

// 2025-01-01
{
  "company": "fr-bourso-bank",
  "loginMethod": "USERNAME_AND_PASSWORD",
  "input": { "USERNAME": "user@example.com", "PASSWORD": "53cr3t_P455W0Rd***" }
}

// 2026-04-01
{
  "company": "fr-bourso-bank",
  "loginMethod": "USERNAME_AND_PASSWORD",
  "parameters": [
    {
      "type": "USERNAME_PASSWORD",
      "username": "user@example.com",
      "password": "53cr3t_P455W0Rd***"
    }
  ]
}

The loginMethod field itself is unchanged in meaning — keep reading the methods a company supports from the /companies/availability response, and pick the parameter that carries that method's credential.

New collection statuses

CollectionStatus gains TWO_FACTOR_METHOD_SELECTION_TIMEOUT, AUTHENTICATION_ERROR and LOGIN_METHOD_NOT_APPLICABLE. Nothing has been removed, but any exhaustive switch over the status enum needs a branch — or a default — for the new values.

Renamed schemas

The French.-prefixed schema names have been dropped. The fields they contain are unchanged, so this only affects generated clients and type names, not the JSON you receive.

2025-01-012026-04-01
French.AccountInformationAccountInformation — also gains hasExclusiveOwnership
French.InsuranceInsurance
French.FrenchHoldingFrenchHolding
French.PayoutDetailFrenchPayoutDetail

Steps

  1. Repoint the base path. Replace /wealth/collection with /collections, and read data from /collections/{collectionId}/wealth/data instead of /wealth/collection/{collectionId}/data. Status and supplement-info keep the same suffixes under the new prefix.
  2. Convert the request body. Move each input key into a typed entry in the parameters array (e.g. USERNAME / PASSWORD{ "type": "USERNAME_PASSWORD", "username": …, "password": … }).
  3. Move consents and session data into parameters. Replace the consents array with the relevant typed consent parameter, and move session identifiers into a SESSION_METADATA parameter's attributes.
  4. Handle the new statuses so an unexpected value does not fall through as a failure.