Item resources

When a product comes back empty, there are two very different reasons behind it, and they lead to opposite next steps:

• the institution never shared it — the consent does not cover it, the user still has to authorise it, or the bank reports it as unavailable. The end user can fix this at their bank;
• we do not hold the record — the consent covers it, but the sync has not brought it in. That is ours to look at.

GET /items/{id}/resources answers the first one. It lists the resources the financial institution declared for this item's consent, exactly as the institution reported them — nothing inferred, nothing merged with our own data.

The response#

The endpoint is paged (page, pageSize, default 500 per page):

{
  "page": 1,
  "total": 3,
  "totalPages": 1,
  "results": [
    { "resourceId": "92792126-fa1e-4e1c-a2b2-5b7b0d4a0b11", "type": "ACCOUNT", "status": "AVAILABLE" },
    { "resourceId": "0d1e2f34-55aa-4b0c-9f3d-77c1a0e2b345", "type": "CREDIT_CARD_ACCOUNT", "status": "PENDING_AUTHORISATION" },
    { "resourceId": "5f6a7b89-1122-4c33-8d44-99e0f1a2b3c4", "type": "FUND", "status": "UNAVAILABLE" }
  ]
}

Each entry has three fields:

Filtering by status#

Pass status to get only the resources in one state, for example GET /items/{id}/resources?status=PENDING_AUTHORISATION. Accepted values: AVAILABLE, PENDING_AUTHORISATION, UNAVAILABLE, TEMPORARILY_UNAVAILABLE. Paging works the same way, and total counts only the matching resources.

Status#

PENDING_AUTHORISATION keeps Open Finance's British spelling. It is the regulation's, not a typo.

Types#

How fresh the list is#

The list is a snapshot from the last execution that actually reached the institution, so it can be older than the item itself. The Item's resourcesCollectedAt says when it was taken.

That field is also what makes an empty list readable:

• resourcesCollectedAt set, empty list → the institution shared nothing under this consent;
• resourcesCollectedAt null → the list has never been obtained. An empty response says nothing about the consent.

Resources pending authorization#

The Item's hasResourcesPendingAuthorization tells you whether anything in this list is waiting on the user, without paging through it. It is read from this same list, so the two always agree.

A typical way to handle it:

1. On item/created or item/updated, call GET /items/{id}.
2. If hasResourcesPendingAuthorization is true, call GET /items/{id}/resources?status=PENDING_AUTHORISATION to see which resources are waiting.
3. Tell your user what they still have to authorise in their bank's app — type says which product each resource belongs to. For business accounts this is often the approval of a second signer.
4. Once the user authorises them, the next update of the item brings their data in, and the following item/updated arrives with hasResourcesPendingAuthorization set to false.

What it does not answer#

Whether Pluggy holds the matching record is a separate question. A resource can be AVAILABLE and still have no data on our side, and the reverse also happens — we keep records across executions, so data can be there from an earlier sync of a resource the institution no longer declares.

For that side, use the product endpoints (/accounts, /investments, /loans) and the Item's statusDetail, which reports per-product collection outcomes. See Item and Warnings & Status Codes.

A worked triage#

A customer reports that an item connected to an Open Finance bank returns no investments.

1. GET /items/{id} — is status UPDATED? What does statusDetail.investments say? If it reports an error, the problem is collection and stops here. INV_002 warnings list the investments still pending authorization at the bank (up to 100), and hasResourcesPendingAuthorization: true says some resource, in any product, is waiting on the user; step 2 has the full list.
2. GET /items/{id}/resources — are there investment types in the list at all? Add ?status=PENDING_AUTHORISATION to see only the ones waiting on the user.
   • none, and resourcesCollectedAt is set → the institution does not share investments under this consent. Nothing to fix on our side;
   • present as PENDING_AUTHORISATION → the user has to authorise that resource at their bank;
   • present as AVAILABLE → the consent covers it and we should have it. That is a collection issue worth reporting, with the item id and the resourceId in hand.

Per-connector coverage tables answer a different question — what a connector supports in general — and live in Connectors coverage. This endpoint answers it for one consent, as the institution declared it today.