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

# Direct Executions — the API without the widget, documented

The second way to use INFONITE now has a section of its own: **[Direct Executions](/direct-executions/overview)** — the same engines, called straight from your backend, for the cases where nobody is in front of a screen.

It is not a new API. It is the one that has been running client integrations for a long time, written down properly for the first time: what to send, what comes back, what each state means, and the decisions that are easy to get wrong.

### The guides

* [**What is a direct execution**](/direct-executions/overview) — when this is the right integration, when a [flow](/guides/what-is-a-flow) is, and what becomes your responsibility when there is no widget in the middle.
* [**Your first execution**](/direct-executions/quickstart) — six calls, as real commands, against a sandbox engine: find the engine, ask what it needs, run it, follow it, read the results, delete them.
* [**Authentication & keys**](/direct-executions/authentication) — the `X-APP-SECRET` header, sandbox versus production, and how to encrypt the credentials you send with your application's public key so that not even an intercepted request body reveals them.
* [**The execution lifecycle**](/direct-executions/lifecycle) — every state, the three clocks, the limits that end a run on their own, and why `PARTIAL` is a finished execution rather than a failed one.
* [**Challenges & MFA**](/direct-executions/challenges) — what to do when the institution asks for a one-time code: reading the form it publishes, answering it, and the deadline you have to beat.
* [**Stored credentials**](/direct-executions/tokenization) — turning one execution into a token so that next month's run needs no password on your side, what a token is scoped to, and what each of its states means.
* [**Webhooks**](/direct-executions/webhooks) — the four execution events, the delivery envelope, and the authentication header your endpoint can require.
* [**Reading the results**](/direct-executions/results) — global positions versus per-product endpoints, the difference between "nothing to report" and "you never asked for it", and the original documents behind the data.

### The reference

The **[Direct Executions API](/direct-executions/api-reference/direct-executions-api/engines/direct-executions-v-1-engines-list)** is in the API Reference tab, beside the flow API, with a request explorer on every operation: the engine catalogue, the execution lifecycle, tokenization, every results endpoint, attachments, and the four webhooks.

> **Note**
>
> **Execution webhooks carry the state, never the data.** An execution event tells you *that* something happened; the records are read back over an authenticated call. That is deliberate — it keeps somebody's financial data off a public endpoint — and it is different from a flow session, which can deliver its results encrypted with a key you supplied.

### Credential tokenization, explained once

**[Credential Tokenization](/guides/credential-tokenization)** is a guide of its own now, in the Security section, because it is not a Direct Executions feature — it is a platform one, and it is coming to the widget flows too, Bank Reader first.

It documents what tokenization actually gives you: the credentials are stored encrypted under a key **derived** from the token key you hold together with a secret that never leaves our runtime, so neither side can open them alone. We keep the ciphertext and a non-reversible verifier of your key, never the key itself.

> **Warning**
>
> **If you lose your token key, the stored credentials can never be opened again — by anyone, including us.** That is the design working, not a failure of it. Store your half as you store any secret you cannot recreate, and mint a new token from a fresh run when you have to.

### Banking data models

The [data models](/guides/data-models/overview) section gains the **[Banking](/guides/data-models/banking/overview)** family — the models any financial engine returns, field by field: [accounts](/guides/data-models/banking/accounts) with their categorised transactions, [cards](/guides/data-models/banking/cards), [loans and mortgages](/guides/data-models/banking/credit), [deposits and savings](/guides/data-models/banking/savings), [investments](/guides/data-models/banking/investments) and [direct debits](/guides/data-models/banking/direct-debits).

Until now that section documented only what comes back from a public administration. Both family maps are on the overview page now, side by side.

### Also on the site

* The **API Reference** now opens by naming the two APIs and what each one is for, with the base URLs of both.
* The [encryption guide](/guides/payload-encryption) finally points somewhere for the RSA envelope used to send values *to* us: the walkthrough now lives with the credentials it protects.
* `clients.infonite.io` is announced as the address the Direct Executions API is moving to; `clients.infonite.tech` keeps serving until it arrives.