What is a direct execution | INFONITE

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

Two ways, and they are the platform’s two. Asynchronous: subscribe to the webhooks and you are told when it starts, when it needs you, and when it ends. Synchronous: 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.

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

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

Going to production

Everything above works in sandbox from the first minute, against engines that answer with realistic, fabricated records — build the whole integration there. Production is a separate request, and so is each capability it needs.

Before production

Direct executions in production

Direct executions run in sandbox from the first minute. Moving the application to production asks which products it will use — choose Direct Executions — and stored credentials need Tokenized access on top: without it, a production run that asks for them answers 403 with insufficient_capabilities@login:tokenized_access.

How to request it

Where to go next

Authentication & keys

Your application secret, sandbox versus production, and how to encrypt credentials so that not even an intercepted request reveals them.

The execution lifecycle

Every state an execution can be in, what closes it, and the difference between COMPLETED and PARTIAL.

Stored credentials

Run the same access again next month without keeping the password.

Reading the results

Global positions, per-product endpoints, official documents, and when to delete it all.

API Reference

Every endpoint and every schema, with a request explorer beside each one.