> This page is for Platform. > 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. # What is a flow A **flow** is a complete journey that works out of the box: we host it, you embed it. You create a session from your backend, send your customer to the URL it returns, and the INFONITE widget takes it from there: it explains what is being asked for, collects consent, walks the person through authenticating with each institution, and hands the records back to your systems. What that buys you is not a UI. It is **not being in the middle of somebody's credentials.** > **Note** > > **The end user's secrets never touch your servers.** They are entered in our widget, used against the institution, and never returned to you. Your integration handles a `session_id` and a set of records — never a password, never a *Cl\@ve* code, never a one-time SMS. --- ## What a flow is made of #### A session you create One server-to-server call from your backend says *who* the customer is, *what* you need (the [features](/guides/features): labor check, taxes, vehicles…) and *how* you want the results delivered. You get back a `widget_url` and a `session_id`. #### An experience we run The widget is a hosted web experience — open it in an iframe, a new tab, or a mobile web view. It adapts to what the chosen institutions actually require: a *Cl\@ve Móvil* push, a QR, an SMS code, a certificate. When an institution changes its login, the flow changes; your integration does not. #### Consent, recorded Before anything is read, the person is shown what will be requested and signs their agreement. That consent is stored as evidence with the session — it is what makes the extraction lawful, and it is auditable afterwards. #### Records, delivered to you Structured data plus the official supporting documents — [pushed to you as webhooks or pulled by polling](/guides/webhooks#synchronous-and-asynchronous), the platform's two ways — the webhooks optionally [encrypted with a key only you hold](/guides/payload-encryption). The redirect that brings your customer back is neither of them: it carries a browser, not records. --- ## What a session hands back, beyond the records Every flow delivers the data it read — and, beside it, a **`messages`** list: situations the session detected while it ran. Most sessions detect none and the list is empty, so an integration that ignores it is not missing anything. The type worth routing is **`flag`**. A flag never means something failed on our side — `warning` and `error` say how the *reading* went — it means the session found something about the person or the data that deserves a decision on yours: a signal a clean, successful verification would not normally carry. Treat it as an input to the rules that already decide when a case needs a human. Two things make it usable rather than decorative. `message_id` is the stable name of the **situation**, so you automate on it and never on the wording; and `location` is a `loc` list — `["data", "customer", "profile"]`, strings for fields and integers for array positions — pointing at the exact part of the results the message is about, so you can show it where that data is shown. > **Note** > > **It is a property of flows, not of one flow**, and each reference documents its own: every type and the `loc` in [Spain Public Administration](/flows/spain-public-administration/overview#what-the-session-tells-you-beside-the-data), and what happens when two banks describe different people in [Financial Rider](/flows/financial-rider/overview#when-the-banks-do-not-agree-on-who-your-customer-is). --- ## It is yours, visually The widget carries **your** brand, not ours. From the console you set the display name your customer reads, the logo, the primary and secondary colours, light or dark, rounded or sharp, and how the experience ends — stay put, redirect, or close the tab, with the parameters you need carried back in the URL. The result is an experience that belongs to your product. To the person using it, it is your onboarding — not a third-party page they were bounced to. #### Redirects & Completion How to bring the customer back where you want them when the widget is done, with the context you need to resume your own process. The settings are the same in every flow; each guide shows them with its own events. Financial Rider Spain Public Administration #### Authentication & keys The application secret your backend calls with, the token the widget signs in with on its own, and the session key that keeps the webhooks readable only by you. The same in every flow; each guide adds what is its own. Financial Rider Spain Public Administration --- ## Flows versus calling the API directly A flow exists because **a person has to be present**: only they can approve access to their own records, and only they can complete an authentication that the institution sends to their phone. That is the dividing line for the whole platform: | | **Flows** | **[Direct executions](/direct-executions/overview)** | | :---------------------------------------- | :------------------------------------ | :--------------------------------------------------------------- | | Who faces the end user | Our widget, wearing your brand | You do, or nobody does | | Who holds the credentials | The person, in our widget — never you | You send them with the request | | Consent | Collected and stored by the flow | Yours to obtain and evidence | | When an institution needs a second factor | The widget handles it | Your integration has to | | Fits when | The person is there, in a browser | You already hold what is needed and want a server-to-server call | #### [Direct Executions](/direct-executions/overview) The other door: the same engines called straight from your backend, for the cases where a person is not in front of a screen — a scheduled refresh, a batch, an access you already hold. --- ## The flows available today #### [Spain Public Administration](/flows/spain-public-administration/overview) Official records from the Spanish administrations — *Vida Laboral* and contribution history, public pensions, AEAT fiscal data and income-tax returns, Cadastre properties with their co-owners, official degrees, DGT driver and vehicle records, and the Banco de España's CIRBE credit registry. #### [Financial Rider](/flows/financial-rider/overview) Open Banking as an experience we host: accounts and their movements, cards, deposits, loans, investments and direct debits, straight from your customer's own banks — up to three in one session, merged into one answer. Read them once, or keep recurring access for reconciliation and monitoring. Before production **Every flow in production needs its capability** Sandbox sessions work from the first minute, for every application. A production session needs the application in production and holding the capability of its flow — **Financial Rider** or **Spain Public Administration** — and is refused without it, with `403` and `insufficient_capabilities@product:…`. How to request it #### [What comes back](/guides/data-models/overview) Every flow returns the same shared models. The data models reference explains each one field by field — read it while you design, not after.