> 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. # What is a direct execution A **direct execution** is one call from your server: *run this engine, with these credentials, for this customer, and get me these records.* Throughout this section, **your customer** means the end customer of your product — the person or company whose credentials these are. An engine logs into the bank, the utility or the public administration on your customer's behalf, extracts what you asked for, and leaves it for you to read back. There is no hosted screen and no redirect. Your backend talks to ours, and nobody has to be looking at anything for it to happen. **Same engines, same data, different door.** Everything a [flow](/flows/overview) can retrieve, a direct execution can retrieve. What changes is who faces the end user — and therefore who holds the credentials, who collects the consent, and who answers the institution when it asks for a second factor. --- ## When this is the right integration #### The experience is yours You are building the journey end to end — your screens, your wording, your steps — and the extraction is one call inside it. Yours to orchestrate, yours to retry, yours to instrument. We provide the connectors and nothing else. #### You already hold the access Your customer gave you their credentials in your own onboarding, under your own consent. You are entitled to use them, and you would rather not send the person through a second experience. #### The work is scheduled, not interactive A nightly refresh of balances, a monthly re-check of employment status, a batch of files re-scored on the first of the month. Nobody is awake for any of it. #### Nobody is in a browser A back-office operator processing a file, a system acting on a corporate account, a document that has to be verified without the holder present. **Use a [flow](/flows/overview) instead** when the person has to be there: when consent is collected in the moment and has to be evidenced by us, when the credentials must never touch your servers, or when the institution will ask for something only their phone can answer and you would rather not build that conversation. | | **Direct executions** | **Flows** | | :------------------------ | :----------------------------- | :------------------------------------ | | Who faces the end user | You do, or nobody does | Our widget, wearing your brand | | Who holds the credentials | You send them with the request | The person, in our widget — never you | | Consent | Yours to obtain and evidence | Collected and stored by the flow | | A second factor mid-login | Your integration answers it | The widget handles it | | Runs unattended | **Yes** | No — a session is a person | --- ## The shape of it #### Find the engine The catalogue tells you what your application may run right now, what each engine needs to log in, and what it can retrieve. Read it rather than hardcoding a form: institutions change what they ask for. **Cache it** — it is a directory, not a live signal, and refreshing it once or twice a day is plenty. #### Start the execution One `POST` with the engine, your `customer_id`, the credentials and the features you want. It answers `202` in milliseconds with an `execution_id` — the work happens behind it. #### Follow it Subscribe to the [webhooks](/direct-executions/webhooks) and you are told when it starts, when it needs you, and when it ends. Or poll: there is a one-byte status endpoint for exactly that. #### Answer, if the source asks Some logins raise a challenge halfway through. The execution parks, publishes the form it needs, and waits for you to send the value — see [Challenges and MFA](/direct-executions/challenges). #### Read the results, then delete them Records and original documents, over an authenticated call. Then purge the execution: the fastest way to protect somebody's financial data is not to be holding it. #### [Your first execution](/direct-executions/quickstart) The whole sequence as real calls you can paste into a terminal, from listing engines to reading the results. --- ## What you are responsible for This is the honest part of choosing this product. With a flow, a lot of this is ours; here it is yours. #### The consent You obtained the person's permission to access their accounts on their behalf, and you can prove it. Nothing in this API collects or evidences that for you. #### The credentials They pass through your systems, so they are yours to protect — in transit, at rest, and in your logs. [Tokenization](/direct-executions/tokenization) exists so that you do not have to keep them. #### The conversation with the institution When a source asks for a one-time code, your product has to ask your customer for it, within a couple of minutes. #### The retries An execution that ends for a temporary reason is not retried on its own. Deciding when to run it again is part of your integration. --- ## Where to go next #### [Authentication & keys](/direct-executions/authentication) Your application secret, sandbox versus production, and how to encrypt credentials so that not even an intercepted request reveals them. #### [The execution lifecycle](/direct-executions/lifecycle) Every state an execution can be in, what closes it, and the difference between `COMPLETED` and `PARTIAL`. #### [Stored credentials](/direct-executions/tokenization) Run the same access again next month without keeping the password. #### [Reading the results](/direct-executions/results) Global positions, per-product endpoints, official documents, and when to delete it all. #### [API Reference](/api-reference/direct-executions/direct-executions-api/engines/direct-executions-v-1-engines-list) Every endpoint and every schema, with a request explorer beside each one.