What is a direct execution
Run an INFONITE engine from your own backend — no widget, no screen, no person in front of one
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
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.
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.
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.
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.
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 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.
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.
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.
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.
When a source asks for a one-time code, your product has to ask your customer for it, within a couple of minutes.
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
Your application secret, sandbox versus production, and how to encrypt credentials so that not even an intercepted request reveals them.
Every state an execution can be in, what closes it, and the difference between COMPLETED and PARTIAL.
Run the same access again next month without keeping the password.
Global positions, per-product endpoints, official documents, and when to delete it all.