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

# Features

An **engine** is a source: a bank, a card issuer, a public administration. A **feature** is one thing that engine can *do* at that source — and usually what it does is retrieve a family of products: the accounts, the cards, an employment record, a tax return. Every request you make on this platform, whatever the product, is a request for features: you name the source, you name what you want done, and each feature answers on its own.

A feature is defined by what it does, not by what it returns. Today every feature reads; the model leaves room for features that act — an engine of a special kind could create something at its source one day — and nothing about how you ask for one would change.

That is the whole model, and it is worth holding onto because it explains three things at once: why two engines of the same bank can offer different features, why an execution can end **partially** complete, and why the results are read one family at a time.

---

## One vocabulary, every product

Feature codes are the same everywhere — in the [Direct Executions API](/api-reference/direct-executions/overview), in a [flow](/flows/overview) session, in the webhooks, in the console. An engine declares the ones it offers; you choose among them.

| Family                    | Features                                                                                                                                                                                              | What comes back                                                                                        |
| :------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------- |
| **Banking**               | `accounts_read`, `cards_read`, `deposits_read`, `loans_read`, `credits_read`, `investment_accounts_read`, `stocks_read`, `funds_read`, `pensions_read`, `direct_debits_read`, `accounts_certificates` | [Banking models](/guides/data-models/banking/overview)                                                 |
| **The customer**          | `customer_information_read`, `source_contracts_read`                                                                                                                                                  | [Customer Profile](/guides/data-models/customer-profile)                                               |
| **Employment & pensions** | `labor_check`, `public_pensions`                                                                                                                                                                      | [Labor Check](/guides/data-models/labor-check), [Public Pensions](/guides/data-models/public-pensions) |
| **Taxes**                 | `yearly_individual_tax`                                                                                                                                                                               | [Taxes](/guides/data-models/taxes)                                                                     |
| **Driver & vehicles**     | `driver_data`, `vehicles_data`                                                                                                                                                                        | [Driver](/guides/data-models/driver), [Vehicles](/guides/data-models/vehicles)                         |
| **Academic**              | `academic_data`                                                                                                                                                                                       | [Academic Records](/guides/data-models/academic)                                                       |
| **Properties**            | `properties_data`                                                                                                                                                                                     | [Properties](/guides/data-models/properties)                                                           |
| **Credit registry**       | `credit_registry_data`                                                                                                                                                                                | [Credit Registry](/guides/data-models/credit-registry)                                                 |
| **Accounting**            | `supplier_invoices_read`, `client_invoices_read`                                                                                                                                                      | Invoices, as attachments                                                                               |
| **Public documents**      | `public_document_verification`                                                                                                                                                                        | The verification, and the document as an [attachment](/guides/data-models/attachments)                 |

**A feature is a capability, not a promise.** An engine lists the features it *can* retrieve; whether a given customer has anything behind one of them — a card, a pension plan — is only known once it runs. A feature that finds nothing completes with an empty result; it does not fail.

---

## Where to see what an engine offers

The list of features, and the settings each one accepts, belong to the engine — and they can change when the institution changes what it exposes. So read them from the platform rather than hardcoding them.

#### [Show Engine Details](/api-reference/direct-executions/direct-executions-api/engines/direct-executions-v-1-engines-details)

One call per engine. `features` carries every feature it offers, each with the **configurations** it accepts as a schema; `parameters` is what it needs to log in; `events` is what a run can notify.

#### [The console](https://infonite.tech/console/engines)

**Engines → open an engine → Integration.** The same features, in reading order, each with its settings — and the three links back to this documentation.

[List Engines](/api-reference/direct-executions/direct-executions-api/engines/direct-executions-v-1-engines-list) filters by feature too: `?features=labor_check&features=yearly_individual_tax` with the default `features_mode=and` returns only the engines that can do both.

---

## Asking for features

```mermaid
flowchart LR
  A["Engine details<br />what it offers, with settings"] --> B["Your request<br />the features you want"]
  B --> C["The run<br />each feature on its own"]
  C --> D["Per-feature outcome<br />and the results, by family"]
```

### In a direct execution

The `features` field of the launch is a list. **A feature is a name, or a name with settings**: send the bare code when the defaults are fine, and an object when they are not.

**`POST /executions/init/v1/parametrized — the features`**

```json title="POST /executions/init/v1/parametrized — the features"
{
  "engine_reference": "DEMOBANKXXXXFIN100ES9999-mobile",
  "customer_id": "my-customer-1",
  "parameters": { "username": "john.doe@example.com", "password": "1234" },
  "features": [
    "customer_information_read",
    {
      "code": "accounts_read",
      "configurations": {
        "read_transactions": true,
        "from_date": "90 days ago",
        "to_date": "today"
      }
    },
    "cards_read"
  ]
}
```

Omit `features` altogether and the engine runs its defaults. Send a feature the engine does not offer and the request is refused before anything runs. The full walkthrough is [Your first execution](/direct-executions/quickstart); the field-by-field reference is [Start an execution](/api-reference/direct-executions/direct-executions-api/starting-executions/direct-executions-v-1-init-parametrized).

### In a flow

A flow puts the widget in front of your customer, so the features are decided **when the session is created** — your backend names them in the [Create Session](/api-reference/spain-public-administration/overview) call — and the customer then sees, and consents to, exactly that scope. The consent webhook carries `accepted_features`, which is the scope worth storing; the results say what actually came back in `retrieved_features`.

Each flow supports the features of the engines behind it, and its overview says which: [Spain Public Administration](/flows/spain-public-administration/overview) today, [Bank Reader](/flows/bank-reader/overview) as it arrives.

---

## Configurations

Most features run with sensible defaults; some accept settings that change what is retrieved. They are declared **per engine and per feature** — the same `accounts_read` may take a date range at one bank and nothing at another — which is why the schema in *Show Engine Details* is the source, not this page.

The settings you will meet most often:

| Setting                             | What it does                                                                                                                                          |
| :---------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `from_date`, `to_date`              | The window of history to read. Dates are forgiving: `"90 days ago"`, `"1 year ago"` and `"today"` are valid alongside a plain `YYYY-MM-DD`.           |
| `limits_behaviour`                  | What to do when the window exceeds what the source allows: `error` refuses the execution, `adapt` trims the range to what is possible and carries on. |
| `read_transactions`, `read_holders` | Whether to go one level deeper for each product — its movements, its holders.                                                                         |
| `filter_by_type`                    | Restrict a family to some of its kinds — the types of cards to read, for instance.                                                                    |

**Ask for what you will use.** Every feature is work at the source, and the deeper settings — transactions over a long window — are the slow ones. A run that asks for less finishes sooner and trips fewer of the institution's limits.

---

## What comes back

Each feature ends on its own. The execution's state lists them with a status each — `FEATURE_COMPLETED`, or the reason it could not — and the execution as a whole is `COMPLETED` when all of them answered, **`PARTIAL`** when some did and some did not. A partial execution is a finished one: read what answered, and the state says what did not and why.

The results are served **by family**, one endpoint per kind of data — accounts, cards, the labor check — so an integration reads the endpoints of the features it asked for. Two answers mean something there:

* **`202`** — the execution, or that feature, has not finished yet.
* **`204`** — the feature was never requested for this execution. Check what you sent in `features`.

[Reading the results](/direct-executions/results) walks through the endpoints; [The execution lifecycle](/direct-executions/lifecycle) explains the states around them; and [Data models](/guides/data-models/overview) describes what each family contains.