Choosing the administrations | INFONITE

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"].

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.

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 Profilecombined`customer_information_read`	YesSMS too	Yes	Yes	Yes	No
Labor Check`labor_check`	YesSMS too	No	No	No	No
Public Pensions`public_pensions`	YesSMS too	No	No	No	No
Credit Registry`credit_registry_data`	Yes, without bde in the list¹	No	No	No	Yes²
Drivercombined`driver_data`	Yes	No	Yes	Yes	No
Vehiclescombined`vehicles_data`	Yes	No	Yes	Yes	No
Taxes`yearly_individual_tax`	No	Yes	No	No	No
Academic Records`academic_data`	No	No	Yes	No	No
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.
¹ 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.
² With bde in your list, the CIRBE report is read here and nowhere else.

The administrations

tgssDefault 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.

aeatDefault list

Cl@ve: a push to the Cl@ve app, or a code by SMS.

citizen_folderDefault 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.

dgtOnly when named

Cl@ve PIN: a short code, sent by SMS and to the Cl@ve app at once.

bdeOnly 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 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:

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.
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.
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:

Social Securitylabor_check, credit_registry_data and the profile

Agencia Tributariayearly_individual_tax, and its part of the profile

Carpeta CiudadanaNever 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:

["tgss"]

Social Securitylabor_check, and the CIRBE report through the Banco de España in the same connection

One sign-in

["tgss", "bde"]

Social Securitylabor_check

Banco de Españacredit_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 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

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.

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 explains the list. How each of these can end a session is in 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. A session that sends allowed_sources always uses its own list.