Cards connected through two sources

Understand includeDuplicates, isDuplicate, and how to avoid counting the same card's spending twice.

The same bank-issued credit card may be connected through the bank and through the card issuer. These are separate connections and source accounts with different accountId values. Both can report the same purchase.

This differs from an old provisional transaction left in your database after the API replaces it. Source filtering addresses the first problem; full account synchronization addresses the second.

Choose the response you need

includeDuplicates is a numeric query parameter:

Value sentBehavior
OmittedSame as 0: apply available duplicate-source filtering.
0Apply available duplicate-source filtering, within the scope described below.
1Include source accounts or transactions without this filtering. Useful for source-specific storage and investigation.
true or falseNot supported query values. Send 1 or 0 respectively.

Accounts: GET /data/accounts

With 0 or omission, matching CARD accounts are collapsed within the current page, preferring the card-issuer account over the bank account when both are present. The matching rule uses the card number's last four digits. With 1, both source accounts can be returned.

Filtering is not a guarantee of one account per physical card across every page or connection filter. Do not use the last four digits alone as a permanent card identity, or assume an account has no other source because it appears in a filtered result.

Transactions: GET /data/transactions

With 0 or omission, the API excludes the matched bank-card account's transactions in favor of the issuer when accountId, connectionId and providerId are all absent. This selects between source accounts; it is not a comparison of every purchase's amount, date or merchant.

With 1, both sources can be returned. When you supply any of those three source filters, this cross-source exclusion is not applied, even with 0. In particular, a full read for one accountId returns that account's own records.

Example: one purchase, two source accounts

Anonymous examples below show selected fields. IDs are illustrative; use returned IDs in actual requests. Both accounts fit in one page in this example.

GET /v2/data/accounts?includeDuplicates=1
Authorization: Bearer <user-access-token>
{
  "items": [
    { "id": "bank-card-account", "connectionId": "bank-connection", "providerId": "leumi", "accountType": "CARD", "accountNumber": "****4242" },
    { "id": "issuer-card-account", "connectionId": "issuer-connection", "providerId": "max", "accountType": "CARD", "accountNumber": "****4242" }
  ],
  "count": 2,
  "nextPage": null
}

For the same pair, GET /v2/data/accounts?includeDuplicates=0 returns only issuer-card-account when both are in the same page. Omission behaves the same way.

GET /v2/data/transactions?includeDuplicates=1
Authorization: Bearer <user-access-token>
{
  "items": [
    { "id": "of-bank-record", "accountId": "bank-card-account", "providerId": "leumi", "amount": { "chargedAmount": { "amount": "120.00", "currency": "ILS" } }, "isDuplicate": false },
    { "id": "of-issuer-record", "accountId": "issuer-card-account", "providerId": "max", "amount": { "chargedAmount": { "amount": "120.00", "currency": "ILS" } }, "isDuplicate": false }
  ],
  "count": 2,
  "nextPage": null
}

With no account, connection or provider filter, changing the request to includeDuplicates=0 gives:

{
  "items": [
    { "id": "of-issuer-record", "accountId": "issuer-card-account", "providerId": "max", "amount": { "chargedAmount": { "amount": "120.00", "currency": "ILS" } }, "isDuplicate": false }
  ],
  "count": 1,
  "nextPage": null
}

However, GET /v2/data/transactions?accountId=<bank-card-account-id>&includeDuplicates=0 still returns the bank account's own record. It does not switch that account to the issuer.

What isDuplicate does—and does not—tell you

isDuplicate is a boolean on transaction responses, intended for duplicate-source marking. It is not a reliable label for every overlapping record: requesting includeDuplicates=1 does not automatically mark the bank copy true. Both copies can have isDuplicate=false, as above. Account responses do not expose this field.

Do not total every row marked false from a response that includes both sources. The flag also does not identify provisional records, record replacements or deletions.

Avoid double counting

  • For a consolidated API view, omit accountId, connectionId and providerId, use includeDuplicates=0, and read every page.
  • For storage by source account, use includeDuplicates=1 and synchronize each account fully. Before calculating local totals, identify which source accounts represent the same card and select one source, normally the card issuer. Do not infer that relationship from the last four digits alone; confirm ambiguous pairs.
  • Keep source selection consistent in your display and calculations. In this example, the expense is ILS 120.00, not the ILS 240.00 obtained by summing both sources.
ProblemCorrect response
Bank and issuer both report the card's purchaseUse supported cross-source filtering or select one confirmed source for totals.
Your database retains an old record no longer in the APIReplace that account's Open Finance records after a successful full-history read.
The API still returns both old and replacement records within one source accountContact Open Finance; includeDuplicates is not a generic transaction deduplication switch.

Did this page help you?