What is a flow
An out-of-the-box, white-label experience that reads a person’s data from their banks and public administrations — with their consent, and without their credentials ever reaching you
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.
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: 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, the platform’s two ways — the webhooks optionally encrypted with a key only you hold. 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.
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, and what happens when two banks describe different people in Financial Rider.
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.
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:
The flows available today
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:….