Read the state | INFONITE

Where an execution is, how long it has taken, what each feature did, and what it is waiting for.

This is the detailed view. For a loop, use Poll the state — it answers with a status code and no body — and come here when it tells you something changed.

Read is_closed first. While it is false the execution is alive and the records can still change. When it is true the run is over and status_reason says how it went — COMPLETED, PARTIAL, or the reason it could not.

What the code tells you

Code	What the body is
`200`	A state you can act on: the execution is closed, or it was rejected over its parameters or configurations and the body names the offending fields.
`202`	Still working. Everything known so far is already there — the features retrieved, the time spent, how the login went.
`423`	An Action Required State: `form_schema` is the form to render and `action_required_expires` your deadline. The answer goes to Resume an Execution.
`404`	No execution with that id for your application, or it has been deleted.

What to read in the body

Field	Why you would read it
`status_code` · `status_reason`	The family and the precise cause. Branch on these, never on `status_message`, which is prose and may change.
`authentication_status`	How the login went, separately from the extraction — `not-performed` until the engine has tried. It is what tells we could not get in from we got in and the data did not come.
`features`	One entry per feature you asked for, with its own outcome. This is how a `PARTIAL` execution tells you what arrived and what did not.
`products_count`	How much was retrieved, by kind — a cheap way to see whether there is anything worth fetching.
`messages` · `warnings_count` · `errors_count`	Notes the engine recorded on the way. Read them when a run ended in a way you did not expect.
`locking_hash`	A stable fingerprint of the fixed part of the credentials, so you can recognise a returning login without storing any of it.

Three times, and the gap between them is the answer. execution_time is active processing, running_time adds whatever was spent waiting for a person, and total_elapsed_time counts from the moment you asked — queue included. All three are in seconds. When a run feels slow, the difference says whether it was us, the source, or your customer.

Server to server only. This call is authorised with your application secret: it belongs in your backend, never in a browser, a mobile app or anything your customer can read.

Where an execution is, how long it has taken, what each feature did, and what it is waiting for. This is the detailed view. For a loop, use [Poll the state](api:HEAD/executions/handler/v1/{execution_id}) — it answers with a status code and no body — and come here when it tells you something changed. <Note> **Read `is_closed` first.** While it is `false` the execution is alive and the records can still change. When it is `true` the run is over and `status_reason` says how it went — `COMPLETED`, `PARTIAL`, or the reason it could not. </Note> ## What the code tells you | Code | What the body is | | :--- | :--- | | `200` | A state you can act on: the execution is closed, **or** it was rejected over its parameters or configurations and the body names the offending fields. | | `202` | Still working. Everything known so far is already there — the features retrieved, the time spent, how the login went. | | `423` | An **Action Required State**: `form_schema` is the form to render and `action_required_expires` your deadline. The answer goes to [Resume an Execution](api:PUT/executions/handler/v1/{execution_id}). | | `404` | No execution with that id for your application, or it has been deleted. | ## What to read in the body | Field | Why you would read it | | :--- | :--- | | `status_code` · `status_reason` | The family and the precise cause. Branch on these, never on `status_message`, which is prose and may change. | | `authentication_status` | How the **login** went, separately from the extraction — `not-performed` until the engine has tried. It is what tells *we could not get in* from *we got in and the data did not come*. | | `features` | One entry per feature you asked for, with its own outcome. This is how a `PARTIAL` execution tells you what arrived and what did not. | | `products_count` | How much was retrieved, by kind — a cheap way to see whether there is anything worth fetching. | | `messages` · `warnings_count` · `errors_count` | Notes the engine recorded on the way. Read them when a run ended in a way you did not expect. | | `locking_hash` | A stable fingerprint of the fixed part of the credentials, so you can recognise a returning login without storing any of it. | <Tip> **Three times, and the gap between them is the answer.** `execution_time` is active processing, `running_time` adds whatever was spent waiting for a person, and `total_elapsed_time` counts from the moment you asked — queue included. All three are in **seconds**. When a run feels slow, the difference says whether it was us, the source, or your customer. </Tip> <Note> **Server to server only.** This call is authorised with your application secret: it belongs in your backend, never in a browser, a mobile app or anything your customer can read. </Note>

Authentication

X-APP-SECRETstring

Application Secret

Path parameters

execution_idstringRequiredformat: "object-id"

The execution, as the acceptance response returned it.

Response

200 OK
A state you can act on. Either the execution is closed — is_closed is true and status_reason says how it went — or it was rejected over its parameters or configurations, and the body names the offending fields.

features is what turns a PARTIAL into something actionable: one entry per feature you asked for, each with its own outcome.

**200 OK**<br>**A state you can act on.** Either the execution is closed — `is_closed` is `true` and `status_reason` says how it went — or it was rejected over its parameters or configurations, and the body names the offending fields. `features` is what turns a `PARTIAL` into something actionable: one entry per feature you asked for, each with its own outcome.

execution_idstringformat: "object-id"

The execution this belongs to — the value you poll for the state and address every results endpoint with. Always present here: an event exists because an execution does.

session_idstringformat: "object-id"

The session this execution belongs to. An execution launched on its own is its own session, so the two values usually match — treat them as independent anyway: an execution can be one step of a wider journey. Address everything by execution_id.

app_idstringformat: "object-id"

The application this execution was launched with — the one your secret belongs to. Worth keeping when your product uses more than one, a sandbox and a production app being the usual case: every record and every event we send carries it.

customer_idstring

The customer_id you supplied when the execution was initialised, returned as you sent it — so an answer can be routed to the right case with no lookup on your side.

engine_referencestringformat: "engine-reference"

The engine this execution runs, exactly as the catalogue publishes it. It is echoed on every event and every record, so a stored result says which source it came from with no lookup on your side.

auth_originenum

How the call that created the execution was authorised: an application secret for a server-to-server call, or a user session when it was launched from a console. An audit field — it says who started the run, not how it went.

status_reasonenum

The precise cause of the state. Every reason belongs to exactly one status_code family and its wording never changes, so it is safe to branch on — read status_code when the family is all you need, and see the lifecycle for what each one asks of you.

Reasons for ONGOING:
- ACCEPTED: queued, nothing has started yet.
- WAITING: picked up, the engine is warming up.
- RUNNING: logged in and extracting.
- ASYNC_WAIT: waiting on the source to produce something on its own schedule.
Reasons for ACTION_REQUIRED:
- MFA_REQUIRED: the source asked for a strong-authentication factor.
- INPUT_REQUIRED: the engine needs another field it could not know in advance.
Reasons for COMPLETED:
- COMPLETED: every requested feature answered.
Reasons for PARTIAL:
- PARTIAL: finished, with some features answered and others not.
Reasons for FAILED:
- FAILED: finished, and nothing could be retrieved.
Reasons for ABORTED:
- CLIENT_CANCELLED: you aborted it.
- USER_CANCELLED: your customer abandoned it.
- ACTION_TIMEOUT: nobody answered the challenge in time.
- TIMEOUT: the run exceeded its execution_timeout.
- CUSTOMER_INTERVENTION_REQUIRED: a person was needed and none was available.
- SYSTEM_CANCELLED: the platform stopped it.
Reasons for AUTH_ERROR — the source refused the login, and retrying the same values will not help:
- INCORRECT_CREDENTIALS: rejected. Ask your customer for them again.
- INCORRECT_MFA: the challenge was answered wrongly.
- BLOCKED_USER: the institution has blocked the access.
- FRIEZED_CREDENTIALS: the access is temporarily frozen.
- CHANGE_PASSWORD: the institution requires a password change first.
- MANUAL_INTERVENTION: the person must do something in the source’s own channel.
- INCOMPATIBLE_ACCESS: this access does not work through this engine’s channel.
- DUPLICATED_SESSION: another session is already open for that user.
Reasons for UNHANDLED_AUTH_ERROR:
- UNHANDLED_AUTH_ERROR: the login failed in a way we could not classify.
Reasons for CONFIGURATION_ERROR — the request itself, so retrying it unchanged fails the same way:
- BAD_CONFIGURATIONS: a feature configuration the engine does not accept.
- INCORRECT_PARAMETERS_FORMAT: the parameters did not match the engine’s form.
- INCORRECT_RESUME_FORMAT: the resume body did not match the published form.
- ENCRYPTION_ERROR: an encrypted value could not be opened.
- T10N_FORBIDDEN: your application may not tokenize.
- T10N_NOT_AVAILABLE: this engine does not support tokenization.
- T10N_REJECTED: the token is revoked or broken.
- T10N_EXCEPTION: the stored credentials could not be read.
- BAD_PROXY_CONFIGURATION: ours, not yours — contact support.
Reasons for TEMPORARY_ERROR — nothing is wrong with your request, retry later:
- OUT_OF_SERVICE: the source itself is unavailable.
- ENGINE_UNAVAILABLE: the engine is not serving right now.
- ALREADY_EXECUTING: another execution is already running for that access.
- ENGINE_BANNED, AUTO_CAPTCHA_ERROR, PROXY_ERROR, NETWORK_ERROR, INTERNAL_ERROR: the run could not be set up. Ours, and transient.

AUTH_OK belongs to this vocabulary too, but it only ever appears in authentication_status: a login that succeeds leaves the execution ONGOING.

products_countmap from strings to integers

How many records of each kind were retrieved — a quick way to see whether an execution brought anything back before you read it. The key is <family>:<subtype>@<product>, so financial_card:credit@financial_card counts the credit cards and financial_card:debit@financial_card the debit ones.

end_hookenum

Whether the ended webhook reached your endpoint. skipped means no rule was bound to it; anything else says how the delivery went, and a failed one is retried in the background.

status_codeenumRead-only

The family a state belongs to, and the value to branch on: it is always present, and every status_reason belongs to exactly one of these. The precise cause lives in the reason — read it when the family is not specific enough to decide. Allowed values are:

ONGOING: The execution is ongoing
ACTION_REQUIRED: The execution is waiting for an input
COMPLETED: The execution has been completed
ABORTED: The execution has been aborted
CONFIGURATION_ERROR: The execution has been rejected due to a configuration error
PARTIAL: The execution has been completed with errors
TEMPORARY_ERROR: The execution cannot be processed due to a temporary error
AUTH_ERROR: The execution failed due to an authentication error
UNHANDLED_AUTH_ERROR: The execution failed during the login because of an unhandled error
FAILED: The execution has failed

is_closedbooleanRead-only

Whether the execution is over. While it is false the state and the records can still change.

warnings_countintegerRead-only

How many of messages are warnings: the execution carried on.

errors_countintegerRead-only

How many of messages are errors. A PARTIAL or FAILED run explains itself here.

external_execution_idstring or nullOptional

locking_hashstring or nullOptional

status_messagestring or nullOptional

authentication_status"not-performed" or enumOptional

How the login went, on its own — separate from how the extraction went. not-performed until the engine has tried, AUTH_OK once the source accepted the credentials, and otherwise the reason it refused them.

It is the field that tells we could not get in from we got in and the data did not come, which are different conversations with your customer.

date_createdstringOptionalformat: "datetime"

When we accepted the request. The clock your customer perceives starts here.

date_startedstringOptionalformat: "datetime"

When the engine picked it up and began working. Everything before this was queue.

date_endedstringOptionalformat: "datetime"

When the execution reached its final state, whatever that state is. Absent while it runs.

running_timedoubleOptional

Elapsed since work began — active processing AND any time spent waiting for a person.

total_elapsed_timedoubleOptional

Elapsed since you asked: queue, processing and waiting. The number your customer feels.

execution_timedoubleOptional

Active processing only. Compare it with total_elapsed_time when a run feels slow: the gap is queue and waiting, not work.

action_required_expiresstringOptionalformat: "datetime"

The deadline for answering a pending challenge. Past it the execution is aborted with ACTION_TIMEOUT and has to be started again.

next_kick_datestringOptionalformat: "datetime"

When the platform will pick this execution up again on its own. It appears while a source is taking its own time (ASYNC_WAIT): nothing to do but wait for the next event.

featureslist of objectsOptional

One entry per feature you asked for, with its own outcome — which is how a PARTIAL execution tells you what arrived and what did not.

configurations_errorslist of objectsOptional

What the engine refused in configurations, field by field. A CONFIGURATION_ERROR says to look here.

parameters_errorslist of objectsOptional

What the engine refused in parameters, field by field — a wrong shape, a missing value, a date outside what this source keeps.

messageslist of objectsOptionalDefaults to []

Notes the engine recorded on the way — information, warnings and errors — each with loc, the feature that raised it. The id and the wording are the engine’s own: read them when a run ended in a way you did not expect, and log them rather than branching on them.

Errors

404

Not Found Error

422

Unprocessable Entity Error

423

Locked Error