Consents Listing and Retrieval

Consents Breaking Changes

The Consents API responses have been updated to support multiple destination accounts and richer account information. These updates affect both listing and retrieval and include breaking changes to an existing field.

Breaking changes

• GET /consents/v1 and GET /consents/v1/{consent_id}: The destination_account_id field in the response has changed.
  • Its required status has changed. Do not assume it is always present.
  • Its type has changed. Update your response model and any strict validators or deserializers to accept the new type.
  • If your integration previously read or validated a single destination_account_id, you must now handle both the updated destination_account_id field and the new destination_account_ids array described below.

What you should change

• Update your response parsing for both endpoints to:
  • Accept the updated destination_account_id type and handle it being absent.
  • Prefer destination_account_ids when present to capture all permitted destinations, and fall back to destination_account_id when only a single destination applies.
  • If you branch logic for immediate payments, also read immediate_payment.destination_account_id when present.

New and expanded response data

• GET /consents/v1 — List customers consents

  • data.[].beneficiary_type is now returned. This identifies the kind of beneficiary covered by the consent and allows you to tailor payment or transfer behavior based on beneficiary category.
  • data.[].destination_account_ids is now returned. Use this to read all destination accounts that the consent allows. This is important if a consent permits multiple destinations.
  • data.[].immediate_payment.destination_account_id is now returned for consents that include immediate payment settings. Use this to determine the destination account specifically for immediate payments under the consent.
  • data.[].consented_account.account_sub_type is now returned. This provides a finer classification of the consented account using the new AccountSubType model.

• GET /consents/v1/{consent_id} — Retrieve consent details

  • beneficiary_type is now returned for the consent, letting you identify the beneficiary category when working with a single consent.
  • destination_account_ids is now returned to enumerate all destination accounts allowed by this consent.
  • immediate_payment.destination_account_id is now returned when the consent defines an immediate payment destination.
  • consented_account.account_sub_type is now returned to indicate the sub-type of the consented account via the AccountSubType model.

New data model

• AccountSubType is introduced and used in consented_account.account_sub_type. Incorporate this into your models to read the more granular account classification where provided.