Reading the results
Results are pulled, never pushed. When an execution closes, everything it retrieved sits behind your application secret, addressed by execution_id, until you read it and delete it.
There are two ways to ask, and they answer different questions:
Everything of one kind in a single object — Financial Position or Public Position. One call, the whole picture, grouped by family, and the one we recommend: the same records the per-product endpoints serve, without making ten requests for them.
One family at a time — accounts, cards, labor check, taxes. Use it when you only need one thing, or when you want to read a feature the moment it finishes rather than waiting for the run.
The three answers, and what they mean
Every results endpoint speaks the same short language. Learn it once:
204 and an empty 200 are very different findings. “We asked and there is nothing” is a business answer you can act on — no properties, no pension, no vehicles. “We never asked” is a bug in your request. The API keeps them apart deliberately; make sure your client does too.
A per-product endpoint answers as soon as its own feature is closed, so a fast feature is readable while a slow one is still running. A position waits for the whole execution, because a half-assembled picture of somebody’s finances or official record is a misleading one — that wait is what it costs, and the nine requests it saves are what it buys.
What comes back
The models are the same ones every product on the platform returns, and they are documented field by field in the data models section — read them while you design, not after.
Accounts and their categorised transactions, cards, loans and mortgages, deposits, investments and direct debits.
Who the source says your customer is: names, documents, contact details, declared situation. Person or company.
The labor check — employers, contribution history, current status and an income floor — and the public pensions being paid.
Income-tax situation year by year, as filed with the tax agency.
Debt reported to the Banco de España, entity by entity — including what your own institution cannot see.
Licences and points, and the vehicles registered to the person with their insurance and inspection state.
Real estate in the official records, and official education records.
Invoices from a utility, a telecom or a supplier portal arrive under /commercial/v1/, received and issued separately, each with the original document attached.
Every family also has its own endpoint per product — /financial/v1/accounts, /public/v1/labor-check, /commercial/v1/supplier-invoices — and the API reference carries the exact schema beside each one.
The original documents
Data is one half; the document it was read from is the other. Where a source issues one — a Vida Laboral report, a tax declaration, a CIRBE report, a utility invoice — the original file is kept with the execution.
List them
List Attachments returns what each document is, its name, type and size — not its bytes. A response carrying six PDFs inline would be enormous and mostly unwanted.
Download the ones you need
Download Attachment streams one file with its own content type and filename.
Results also reference their own documents inline — attachments inside a labor check, for instance — with the same identifiers, so you can go straight from a record to the paper behind it. The catalogue of document types is in Attachments.
These are the evidence. They are signed or stamped by the institution that issued them, which is what makes a file stand up to an audit months later. If your process needs to defend a decision, store the document, not just the number you extracted from it.
Then delete it
Reading is not the last step. Deleting is.
Delete an Execution purges the execution, its records and its documents, permanently. Call it as soon as you have stored what you need — the strongest protection available for somebody’s financial data is not to be holding it.
Executions nobody deletes are purged after the platform’s retention period. That is a safety net for the ones you miss, not a data-minimisation policy: the policy is yours, and this endpoint is how you enforce it.