> This page is for Spain Public Administration Flow. > 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. # Choosing the administrations A session reads the features you name in `settings.executions_features`, and every administration it reads them from is **one more sign-in for your customer**, with its own verification step. `settings.allowed_sources` is how you decide which administrations those can be, and in which order the session asks for them. It is optional: without it, the session uses your application's default list and, without one, `["tgss", "aeat", "citizen_folder"]`. > **Note** > > **It limits sign-ins, not data.** Leaving an administration out means your customer is never asked to sign in there. A feature you request is still delivered when an administration you do allow returns it: leaving `dgt` out never removes `driver_data` while the Social Security or the Carpeta Ciudadana can return it. The one exception is the CIRBE report with `bde` in the list — [below](#the-cirbe-report-and-bde). --- ## Who returns what Nine features, five administrations. Each row is something you can ask for, each column an administration your customer may sign in to, and a tick is a feature that administration returns.
In the default list Only when named
Feature Social Security `tgss` Agencia Tributaria `aeat` Carpeta Ciudadana `citizen_folder` DGT `dgt` Banco de España `bde`
[Customer Profile](/flows/spain-public-administration/data-models/customer-profile) combined customer_information_read Yes SMS too Yes Yes Yes No
[Labor Check](/flows/spain-public-administration/data-models/labor-check) labor_check Yes SMS too No No No No
[Public Pensions](/flows/spain-public-administration/data-models/public-pensions) public_pensions Yes SMS too No No No No
[Credit Registry](/flows/spain-public-administration/data-models/credit-registry) credit_registry_data Yes, without bde in the list 1 No No No Yes 2
[Driver](/flows/spain-public-administration/data-models/driver) combined driver_data Yes No Yes Yes No
[Vehicles](/flows/spain-public-administration/data-models/vehicles) combined vehicles_data Yes No Yes Yes No
[Taxes](/flows/spain-public-administration/data-models/taxes) yearly_individual_tax No Yes No No No
[Academic Records](/flows/spain-public-administration/data-models/academic) academic_data No No Yes No No
[Properties](/flows/spain-public-administration/data-models/properties) properties_data No No Yes No No
* **SMS too**: also without Cl\@ve, by a code the Social Security sends to the phone registered with it. Everything else needs Cl\@ve. * **combined**: every administration your customer signs in to that holds it returns its part, and the parts are combined into one — so a later sign-in completes it rather than repeating it. * **1** Through the Banco de España, in the same connection as the Social Security's Cl\@ve sign-in, which may ask your customer to confirm once more. Never with `bde` in your list. * **2** With `bde` in your list, the CIRBE report is read here and nowhere else. --- ## The administrations `tgss`Default list **Cl\@ve**: a push to the Cl\@ve app, or a code by SMS. **Without Cl\@ve**, a code the Social Security sends to the phone registered with it, with the identity document and the date of birth: it reads `labor_check`, `public_pensions` and `customer_information_read`. `aeat`Default list **Cl\@ve**: a push to the Cl\@ve app, or a code by SMS. `citizen_folder`Default list **Cl\@ve**: a push to the Cl\@ve app, or a code by SMS. It gathers what other bodies hold: the degrees, from the education registries; the properties, from the Catastro; the licence and the vehicles, from the DGT. `dgt`Only when named **Cl\@ve PIN**: a short code, sent by SMS and to the Cl\@ve app at once. `bde`Only when named **Cl\@ve**, at the level the Banco de España requires for the CIRBE report. The request is filed with your customer's email and date of birth — [below](#the-cirbe-report-and-bde). The DGT and the Banco de España are not in the default list: a session reaches them only when its list, or your application's, names them. --- ## How the order is used The list is an order of preference, and the session walks it forward: ```mermaid flowchart TB ask["What you ask for"]:::io --> first["The first administration in your list
that returns something you asked for"] first -->|"then, further down the list"| next["The next one that still has something to add,
and so on, never back up the list"] next -->|"nothing more to add"| done["The session ends"]:::io classDef io stroke-width:1.5px ``` 1. It goes to the **first** administration in the list that returns something you asked for and do not have yet — the customer profile aside, as explained below. 2. When that one is done, it goes to the next one that still has something to add, until everything you asked for is in or nothing left in the list can add to it. 3. **It never goes back.** Once an administration has been used, the ones before it in the list that were not used are not offered again. Put first the one you want your customer to meet first. An administration that has nothing new to add is never offered. When one is used anyway, it also returns what it holds of the **customer profile, the driving licence and the vehicles**, even if another administration already did: those three are combined from every administration that returns them, so a later sign-in completes them rather than repeating them. `customer_information_read` follows the others. It is read from the administrations your customer signs in to anyway, and it adds a sign-in of its own only when none of them returns it — the Banco de España, for instance, does not. If an administration could not return it after your customer signed in, no other one is opened for it. When it is the only feature you ask for, it behaves like any other: the session goes down the list until one returns it. Asking for `customer_information_read`, `labor_check`, `credit_registry_data` and `yearly_individual_tax`, with the default list: 1**Social Security**`labor_check`, `credit_registry_data` and the profile 2**Agencia Tributaria**`yearly_individual_tax`, and its part of the profile **Carpeta Ciudadana**Never offered: nothing missing that it returns --- ## The CIRBE report and `bde` Both ways read the same report, issued by the Banco de España. What changes is the sign-in that reaches it: Asking for `labor_check` and `credit_registry_data`: 1**Social Security**`labor_check`, and the CIRBE report through the Banco de España in the same connection One sign-in 1**Social Security**`labor_check` 2**Banco de España**`credit_registry_data` Two sign-ins | List | What your customer does | Where its strength is | | :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------- | | `tgss`, without `bde` | Signs in at the Social Security with Cl\@ve; the report comes with that same connection, and may ask for a second MFA if the Banco de España requires it | No extra sign-in when you also read the work history or the pensions | | `bde` | Signs in at the Banco de España's own service, and nowhere else for the report | A session that reads nothing from the Social Security, or that should not reach it | **With `bde` in the list, the report is read from the Banco de España and from no other administration** — even when the Social Security comes first. `["tgss", "bde"]` with `labor_check` and `credit_registry_data` is therefore two sign-ins: the work history at the Social Security, then the report at the Banco de España. Two fixed parameters concern the report: * **`fixed_parameters.user_email` is required** whenever `credit_registry_data` is asked for, whichever way it is read: the report is requested with it. A session without it is refused when it is created. * **`fixed_parameters.birth_date` is optional, and only used with `bde`.** The Banco de España's own service files its request with it: when you give it, your customer is not asked for it; when you do not, the widget asks them on the Banco de España's screen. Through the Social Security, the date comes from the person's own record there. The report takes about 8 to 12 minutes to be ready. The session does not wait for it: your customer moves on to the next administration, and the `partial` [webhook](/flows/spain-public-administration/webhooks) delivers what is already in. --- ## Choosing by goal | You want | A list that does it | What your customer goes through | | :------------------------------------------------------------------ | :------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------- | | Work history, pensions and the CIRBE report | `["tgss"]` | One sign-in, at the Social Security — plus a second MFA if the Banco de España requires it for the report | | The CIRBE report alone, from the Banco de España | `["bde"]` | One sign-in, at the Banco de España | | Work history, and the CIRBE report from the Banco de España | `["tgss", "bde"]` | → Two sign-ins: the Social Security, then the Banco de España | | The driving licence and the vehicles from the DGT itself | `["dgt"]`, or `["dgt", "tgss"]` to read more after it | The DGT first; the Social Security only for what the DGT does not return | | The driving licence and the vehicles with a sign-in you need anyway | `["tgss", "dgt"]` | The Social Security returns them; the DGT is offered only if it could not | | Income tax | `["aeat"]`, or `["tgss", "aeat"]` with the Social Security's records | One sign-in at the Agencia Tributaria, after the Social Security's when both are used | | Academic degrees or properties | `["citizen_folder"]` | One sign-in at the Carpeta Ciudadana | > **Tip** > > **Put first the administration that returns most of what you ask for.** What it returns is then never a reason to go to the next one, and your customer signs in fewer times. --- ## When your customer cannot sign in somewhere | What happens | What the session does | What it tells you | | :---------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------- | | Your customer is not registered in Cl\@ve | No administration that needs Cl\@ve is offered again. The Social Security, when it is in the list, is still read through its SMS sign-in | `clave_not_registered` | | Their Cl\@ve registration is below the level an administration requires | That administration is not offered again in the session: trying again does not change the level. The Banco de España requires a higher level for the CIRBE report | `clave_level_insufficient` — at `["data", "credit", "registry"]` when it is the CIRBE report | | They chose the Cl\@ve app and have not activated it | They sign in again choosing SMS. The refused attempt counts as one of the three an administration allows | — | | Three sign-ins fail at the same administration | That administration is closed for the session and the next one in the list goes on. At the Social Security, the SMS sign-in is offered instead | `clave_access_unavailable`, when it was the Cl\@ve access that failed or was blocked | | They abandon a connection in progress | Before signing in, the same administration is offered again: an abandon is not a failed sign-in. After signing in, what had arrived is kept and the next administration in the list goes on | — | Each of those is an `info` message in the session's results; [What the session tells you](/flows/spain-public-administration/overview#what-the-session-tells-you-beside-the-data) explains the list. How each of these can end a session is in [How a session ends](/flows/spain-public-administration/overview#how-a-session-ends). --- ## What is refused when the session is created * **A feature no administration in the list returns.** `["yearly_individual_tax"]` with `["tgss"]` is refused with an error on `settings.allowed_sources` that names the features left without one. A contradiction is better told when you create the session than discovered as a feature that never arrived. * **`credit_registry_data` without `fixed_parameters.user_email`**, wherever the report would come from. * **No feature at all.** Leave `executions_features` out and the session reads your application's default; with neither, it is refused. An administration named twice counts once, at its first position. --- ## Your application's default The default list can be set for your application, so that every session that names none uses it, in its order. To have one set, write to [support@infonite.tech](mailto:support@infonite.tech). A session that sends `allowed_sources` always uses its own list.