> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://infonite.dev/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://infonite.dev/_mcp/server. # 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: #### A position 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. #### A single product 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: | Status | Meaning | What to do | | :----- | :----------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------- | | `200` | Here is the data. | Read it. **An empty list is a `200`** — the feature ran and the source has nothing of that kind. | | `202` | Not ready. The execution, or that feature, is still working. | Wait. This is not an error. | | `204` | **The feature was never requested for this execution.** | Look at what you sent in `features` — this is almost always an integration mistake, not a source that came back empty. | **`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. #### [Banking](/guides/data-models/banking/overview) Accounts and their categorised transactions, cards, loans and mortgages, deposits, investments and direct debits. #### [Customer profile](/guides/data-models/customer-profile) Who the source says your customer is: names, documents, contact details, declared situation. Person or company. #### [Employment & pensions](/guides/data-models/labor-check) The labor check — employers, contribution history, current status and an income floor — and the public pensions being paid. #### [Taxes](/guides/data-models/taxes) Income-tax situation year by year, as filed with the tax agency. #### [Credit registry](/guides/data-models/credit-registry) Debt reported to the Banco de España, entity by entity — including what your own institution cannot see. #### [Driver & vehicles](/guides/data-models/vehicles) Licences and points, and the vehicles registered to the person with their insurance and inspection state. #### [Properties & academic](/guides/data-models/properties) 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](/api-reference/direct-executions/direct-executions-api/fetching-the-results/financial-data/direct-executions-v-1-results-financial-position) 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](api:GET/executions/results/\{execution_id}/attachments/v1/all) 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](api:GET/executions/results/\{execution_id}/attachments/v1/\{attachment_id}) 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](/guides/data-models/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](api:DELETE/executions/handler/v1/\{execution_id}/delete) 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. #### [The lifecycle](/direct-executions/lifecycle) What `PARTIAL` means for the data you just read, and why a finished execution is not always a complete one.