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:
The three answers, and what they mean
Every results endpoint speaks the same short language. Learn it once:
200 means final and 202 means still going, on the Direct Executions results and on a widget flow’s session and results alike. The body never changes with the code — what changes is whether there is any point in asking again.
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 — with a 202, because the execution as a whole has not finished. Those records are final: a closed feature does not change. The code is about the RUN, not about what you are holding. 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.
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.