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, in a flow session, in the webhooks, in the console. An engine declares the ones it offers; you choose among them.

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.

List Engines 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

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.

{
  "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; the field-by-field reference is Start an execution.

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 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 today, Bank Reader 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:

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 walks through the endpoints; The execution lifecycle explains the states around them; and Data models describes what each family contains.