For Data API and Verification in the UK only.
Starling have a new, better API. We’re now moving over to that. This will mean a more reliable service via Starling in the future.
The current integration is highly incident prone and has caused multiple outages in our service to Starling in the last 12 months. This breaking change will impact all clients of data and verification in the UK. This document does not apply to the Payments API.
List of changes
- Requests to
/accounts/${account_id}/transactions
for the same /account_id
will return transactions with different transaction_ids
in the new integration from the old integration
- Clients may instead wish to use the
provider_transaction_id
for reconciliation, as this field’s value will be unchanged
- At present
oauth-starling
returns the account holder’s name in the display_name
field of the /accounts
response. ob-starling
will return the account name instead eg: “personal”, “joint” etc. (The Account holder name is still available in /info
which is where it was before but it was also in /accounts
)
- Changes to the meta fields for the
/transactions
endpoint:
- The field name
provider_source
in meta object is now referred to asprovider_category
provider_transaction_id
is now returned in the response as per TrueLayer documentation
- For
ob-starling
the Description field will no longer be pre-fixed by the counterparty name.
- If you require
counter_party_perferred_name
, the field you should look at isprovider_merchant_name
which is in the meta object. This is populated by a field in the OB spec,merchantdetails.merchantname
, however, it is an optional field and therefore we cannot guarantee it is always populated.
- As a general point across all open banking spec providers, we populate
meta.counter_party_preferred_name
with creditor or debtor account name. Where neither of these 2 fields is supplied,meta.counter_party_preferred_name
is not present.
Client impact
- If you have hard-coded provider-IDs into your product and do not change the provider ID to
ob-starling
, the change will mean end users are unable to grant new consents
- If your auth link is configured to have
oauth-starling
, you will need to reconfigure it to have ob-starling
- For all clients: Since Starling also offer the ability for end users to reauthenticate AIS consent within the Starling banking app, some consents will be broken when we turn off
oauth-starling
. We do not have visibility of the magnitude of consents that are re-authenticated in this way
Client actions
Key dates
- From 03-10-2022 at 11am BST:
- A new provider-ID
ob-starling
will exist in the providers endpoint in public beta
- Requests for new auth URIs for
oauth-starling
will no longer be possible;
- Token refresh and resource requests for
oauth-starling
will continue to work for 90 days.
- From 09-01-2023:
oauth-starling
refreshes & resource requests will no longer be possible
- All requests to Starling will need to be made to
ob-starling
as it will be the only provider ID that you can use
ob-starling
will be available in GA
If you have any questions please create a ticket on our Help Centre and our Client Operations team will be in touch as soon as possible.