> 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. # Initiate with parameters POST https://clients.infonite.tech/api/executions/init/v1/parametrized Content-Type: application/json Start an execution: an engine logs into the source with the credentials you send and retrieves the features you asked for. The call returns immediately with `202 Accepted` and an `execution_id`. Nothing has run yet — the job is queued, and from here on you follow it with the state endpoints or with [webhooks](/direct-executions/webhooks). ## Choosing a `customer_id` This is **your** identifier for the person or company the credentials belong to, and it is the thread that ties everything about them together: every execution, every event we deliver and every record we keep carries it. It is how a support conversation finds what happened to one customer, and what your usage figures are grouped by. A monthly refresh of bank data, a periodic re-check of employment. Send the **stable id of that customer in your own database**: repeating the same value is precisely what makes successive executions read as one person, and what turns them into a history worth having. A single check, a case opened and closed. The **identifier of that operation** does the job just as well — nothing on our side validates the value, so send whatever you can trace back later. **Never put personal data in it.** No national id, no email, no phone number, no name. It travels in the URL of the webhooks we deliver, it is quoted in support tickets and it is stored with the execution. An internal key or a UUID is the right shape; a DNI is not. ## What to send | Field | What it is for | | :---------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `engine_reference` | The engine to run, from [List Engines](api:GET/config/engines/list). | | `parameters` | The fields [Show Engine Details](api:GET/config/engines/\{engine_reference}) declares for that engine. Values — or the whole object — may travel encrypted as `rsa::…` or `hybrid::…`. | | `features` | What to retrieve, each with its own settings. Omit it and the engine runs its defaults. | | `external_execution_id` | Optional, and entirely yours — we store it, echo it back and never read it. It reaches your webhook URL as `{external_execution_id}`, and a different value per run is what lets you execute the same engine twice for one customer at once. | | `base_configurations` | How the execution behaves: see below. | | `hooks_extra_data` | A flat dictionary appended to every webhook delivery as query parameters — the natural place for your case id. **Never for secrets.** | **`base_configurations.customer_interaction_available` decides the shape of your integration.** `true` says somebody can answer a challenge from the source within minutes, so the execution pauses and waits for you. `false` says nobody is there: it runs at low priority, has up to three hours to find a good moment, and **ends** rather than waits if the source asks for a second factor. Two more live here: `execution_timeout` (active processing, 60–1200 seconds) and `tokenized_access`, which asks for a `ticket` so these credentials can be reused later without storing them — see **Getting a ticket back**, just below. ## Getting a ticket back The `202` carries a **`ticket`** only when the request asked for one: set `base_configurations.tokenized_access` to `true`. Leave it at its default and the field is simply absent — it is never part of an ordinary answer. A ticket is single-use and shown once. Exchange it at [Exchange a Ticket](api:PUT/executions/t10n) for the token that runs this same access again, with no password on your side. **Your application has to be allowed to tokenize**, and the request cannot decide that: credential tokenization is a capability granted **per application**, and it has to be enabled — requested is not yet enabled. Ask for `tokenized_access` without it and the call answers `400` with `status_reason: T10N_FORBIDDEN`, and no execution is created. [Credential Tokenization](/guides/credential-tokenization) is the explanation: which half each side holds, how long a token lives, and how to have it turned on for an application. ## What the answers mean | Status | Meaning | | :----- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `202` | Accepted and queued — `status_reason` is `ACCEPTED`. | | `400` | **The execution was viable; one detail makes it impossible.** The request is complete — a malformed one answers `422` — and we saw the impediment before initialising anything, so you get the answer now instead of an execution that could never have worked. `status_reason` says which, **from the same vocabulary a finished execution uses**, so the branch that handles a failure handles this too; there is no `execution_id`, because nothing was created. Two cases: `CUSTOMER_INTERVENTION_REQUIRED`, the engine needs a person at every run and you declared none, and `T10N_FORBIDDEN`, you asked for `tokenized_access` and your application may not tokenize. | | `409` | **An execution matching this one is already running, and the body names it** — see below. | | `503` | The engine is temporarily unavailable. Retry later; nothing is wrong with your request. | ## When one is already running A `409` is **less an error than a pointer**, and that is the whole difference between the two refusals: a `400` never carries execution ids, because nothing was created; a `409` always does, and they name the run to follow. The platform refuses a second run against the same access — some institutions treat two simultaneous logins as an attack — and hands you the one already in flight: ```json title="409 — the run already in flight" { "execution_id": "6aa3d8b418d1c5dc9a8e3d36", "session_id": "5aa3dca503e37e6809539a58", "app_id": "4aa3dcbab3287e2385bb5cec", "auth_origin": "app-secret", "customer_id": "my-customer-1", "engine_reference": "DEMOBANKXXXXFIN100ES9999-mobile", "external_execution_id": "case-A-1029", "status_reason": "ALREADY_EXECUTING", "status_code": "TEMPORARY_ERROR" } ``` **`execution_id` is the run that already exists, not the one you just asked for** — nothing was created by this call. So the useful response is almost never to retry: [follow that execution](api:GET/executions/handler/v1/\{execution_id}) instead, answer its challenge if it is waiting for one, and read its results when it closes. A customer who double-submits your form gets one extraction and one answer, which is what you wanted anyway. Three things collide, and knowing which tells you what to do: | What matched | What it means | | :----------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | | The same **customer and engine**, still running | The obvious one. Follow it. | | The same **`external_execution_id`** for that customer | Your own reference is already in flight. Follow it — or send a different reference if the two runs are genuinely different. | | The same **token** | A tokenized run against those credentials is already going. Follow it. | **If you meant them to run side by side**, give each one a different `external_execution_id`. That is what the field is for, and it is the only way to have two executions of one engine for one customer at the same time. **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. A leaked secret launches executions on your account. Reference: https://infonite.dev/api-reference/direct-executions/direct-executions-api/starting-executions/direct-executions-v-1-init-parametrized ## Authentication - `X-APP-SECRET` header (required) — Application Secret ## Servers - `https://clients.infonite.tech/api` (Legacy Server, default) - `https://clients.infonite.io/api` (Production Server) ## Request ### Body (application/json) This endpoint expects an object. - `engine_reference` (string, required) — The engine to run, as [List Engines](/api-reference/direct-executions/direct-executions-api/engines/direct-executions-v-1-engines-list) publishes it — one source through one access channel, and the same string on every later event and record. Read it from the catalogue rather than building it: which engines your application may run, and which of them are answering right now, is a question only the catalogue can answer. A reference that is unknown, disabled for you or out of service is refused before anything runs. - `customer_id` (string, required) — Your own identifier for the person or company these credentials belong to. Send the **stable id you use in your system** when the same access is run again over time — repeating a value is how successive executions read as the same customer — and for a one-off, the identifier of that operation does the job just as well. It travels in every event we deliver and is stored with the execution, so **keep personal data out of it**: an internal key or a UUID, never a national id or an email. The endpoint description explains how to choose it. - `parameters` (map from string to any, required) — What the engine needs to log in — the fields [Show Engine Details](/api-reference/direct-executions/direct-executions-api/engines/direct-executions-v-1-engine-details) declares for it, under the names it declares them. These are somebody else's credentials, so they can travel **encrypted end to end**: send a value as `rsa::…` or `hybrid::…`, or the whole object as one encrypted string, and not even an intercepted request body reveals them. [How to encrypt them](/guides/payload-encryption#sending-values-in-the-other-direction). - `external_execution_id` (string, optional) — Your own reference for this run — a case number, a job id, whatever your system calls it. We store it, echo it back on every state and event, and offer it as `{external_execution_id}` in the URL of the webhooks we deliver. We never interpret it. It has one effect: a second execution with the same reference, for the same customer and still running, is refused with `409`. That is also what lets you run one engine twice at once — give each run a different reference. - `base_configurations` (object, optional) — The same settings, plus the one only a run WITH credentials can ask for: `tokenized_access`, which returns a `ticket` so this access can be repeated later without keeping the password. - `customer_interaction_available` (boolean, optional, default: false) — Whether somebody is there, right now, to answer a challenge from the source. **This is what decides whether the source is allowed to contact your customer.** With `false`, an engine that needs a one-time code does not ask for one: no SMS, no push notification, no e-mail — the execution ends as `ABORTED` / `CUSTOMER_INTERVENTION_REQUIRED` instead. That is the setting a nightly batch wants: nobody is woken at 03:00 for a run nobody is watching. With `true` the execution pauses, an `action_required` event is delivered and you have minutes — the institution's timetable — to send the answer back. - `execution_timeout` (integer, optional, default: 1200) — Maximum allowed active processing time in seconds. The execution will automatically abort if it exceeds this duration. - `unlock_protected_data` (boolean, optional, default: false) — If true, the engine can unlock data protected by multi-factor authentication (MFA). - `tokenized_access` (boolean, optional, default: false) — Ask for a `ticket` in the answer, so these credentials can be reused later without storing them. Requires the tokenization capability on your application; asking without it is refused with `400` and `T10N_FORBIDDEN`. - `features` (list of object, optional) — What to retrieve. Every feature is a name — `accounts_read`, `labor_check` — and you may send it as the bare string, or as an object when you want to configure it: `{"code": "accounts_read", "configurations": {…}}`. The features an engine offers, and the settings each one accepts, are in [Show Engine Details](/api-reference/direct-executions/direct-executions-api/engines/direct-executions-v-1-engine-details). Ask for one it does not implement and it is **ignored**: no data, no error, and nothing in the results to say it was skipped — which is why the list is built from the catalogue. **Ask only for what you will use**: each feature is more time inside the source, and a slow one holds the whole execution. - `code`: `academic_data` (Academic Data) - `configurations` (object, optional) - `code`: `accounts_read` (Financial Accounts Read) - `configurations` (object, optional) - `from_date` (date, optional, default: 30 days ago) — The date from which the sub-product will be read - `to_date` (date, optional, default: today) — The date until which the sub-product will be read - `limits_behaviour` (enum, optional, default: error) — The behaviour when the date limits are not respected. - `error`: raise an error and abort the execution - `adapt`: adapt the dates to the limits and continue the execution - Allowed values: `error`, `adapt` - `read_transactions` (boolean, optional, default: false) — If true, the engine will try to read the account transactions - `read_holders` (boolean, optional, default: false) — If true, the engine will try to read the account holders - `code`: `cards_read` (Financial Cards Read) - `configurations` (object, optional) - `from_date` (date, optional, default: 30 days ago) — The date from which the sub-product will be read - `to_date` (date, optional, default: today) — The date until which the sub-product will be read - `limits_behaviour` (enum, optional, default: error) — The behaviour when the date limits are not respected. - `error`: raise an error and abort the execution - `adapt`: adapt the dates to the limits and continue the execution - Allowed values: `error`, `adapt` - `read_transactions` (boolean, optional, default: false) — If true, the engine will try to read the card transactions - `filter_by_type` (list of enum, optional, default: ["financial_card:credit","financial_card:mixed","financial_card:debit","financial_card:prepaid"]) — The types of cards to be read. By default all types are requested - Allowed values: `financial_card:debit`, `financial_card:credit`, `financial_card:prepaid`, `financial_card:mixed` - `code`: `client_invoices_read` (Client Invoices Read) - `configurations` (object, optional) - `from_date` (date, optional, default: 30 days ago) — The date from which the sub-product will be read - `to_date` (date, optional, default: today) — The date until which the sub-product will be read - `limits_behaviour` (enum, optional, default: error) — The behaviour when the date limits are not respected. - `error`: raise an error and abort the execution - `adapt`: adapt the dates to the limits and continue the execution - Allowed values: `error`, `adapt` - `code`: `credit_registry_data` (Credit Registry Data) - `configurations` (object, optional) - `preferred_type` (enum, optional) — Preferred credit registry report type to retrieve - Allowed values: `credit_registry_data:es_cirbe_detailed`, `credit_registry_data:es_cirbe_aggregated` - `code`: `credits_read` (Financial Credits Read) - `configurations` (object, optional) - `from_date` (date, optional, default: 30 days ago) — The date from which the sub-product will be read - `to_date` (date, optional, default: today) — The date until which the sub-product will be read - `limits_behaviour` (enum, optional, default: error) — The behaviour when the date limits are not respected. - `error`: raise an error and abort the execution - `adapt`: adapt the dates to the limits and continue the execution - Allowed values: `error`, `adapt` - `read_transactions` (boolean, optional, default: false) — If true, the engine will try to read the credit transactions - `read_holders` (boolean, optional, default: false) — If true, the engine will try to read the credit holders - `code`: `customer_information_read` (Customer Information Read) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `deposits_read` (Financial Deposits Read) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `direct_debits_read` (Direct Debits Read) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `driver_data` (Driver Data) - `configurations` (object, optional) - `read_point_movements` (boolean, optional, default: false) - `code`: `funds_read` (Investment Funds Read) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `investment_accounts_read` (Investment Accounts Read) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `labor_check` (Labor Check) - `configurations` (object, optional) - `from_date` (date, optional, default: 12 months ago) — The date from which the contribution history will be retrieved - `work_life_report` (boolean, optional, default: true) — Whether to read the work life report. - `contribution_base_report` (boolean, optional, default: false) — Whether to read the contribution base report. - `code`: `loans_read` (Financial Loans Read) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `pensions_read` (Pension Plans Read) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `properties_data` (Properties Data) - `configurations` (object, optional) - `code`: `public_document_verification` (Public Document Verification) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `public_pensions` (Public Pensions) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `source_contracts_read` (Source Contracts Read) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `stocks_read` (Investment Stocks Read) - `configurations` (object, optional) — This feature does not require any configuration - `code`: `supplier_invoices_read` (Supplier Invoices Read) - `configurations` (object, optional) - `from_date` (date, optional, default: 30 days ago) — The date from which the sub-product will be read - `to_date` (date, optional, default: today) — The date until which the sub-product will be read - `limits_behaviour` (enum, optional, default: error) — The behaviour when the date limits are not respected. - `error`: raise an error and abort the execution - `adapt`: adapt the dates to the limits and continue the execution - Allowed values: `error`, `adapt` - `code`: `vehicles_data` (Vehicles Data) - `configurations` (object, optional) - `simple_vehicle_report` (boolean, optional, default: false) - `code`: `yearly_individual_tax` (Yearly Taxes for Individuals) - `configurations` (object, optional) - `last_n_years` (integer, optional, default: 3) — Last n years to retrieve the tax data. - `hooks_extra_data` (map from string to string, optional, default: {}) — Your own context, carried into every webhook this execution delivers. Each key and value is appended to the delivery as a **query parameter**, so a handler reads it without opening the body. A value may also be a template variable — `{external_execution_id}`, `{event}`, `{status_reason}`… — replaced with this execution's own data at send time; anything else is sent verbatim. The full list, and the rest of the delivery contract, is in [Webhooks](/direct-executions/webhooks). **Never put secrets here.** Query strings end up in access logs and proxies; your endpoint's authentication belongs in its header. - `configurations` (map from string to any, optional) — Engine-specific settings, and **almost always empty**. An engine takes what it needs through `parameters` and `features`; this is for the rare source that asks for something structural on top, and that engine declares exactly what in its own spec at [Show Engine Details](/api-reference/direct-executions/direct-executions-api/engines/direct-executions-v-1-engine-details). If you are wondering whether the engine you are integrating needs one: it does not. The handful that do are unmistakable about it. ## Response ### 202 **202 Accepted****Accepted, not finished.** The execution is queued; what the source says comes later, in the state and in the events. - `app_id` (string, required) — 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_id` (string, required) — 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. - `auth_origin` (enum, required) — 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. - Allowed values: `app-secret`, `user-token`, `session-token` - `engine_reference` (string, required) — 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. - `status_reason` (enum or enum or enum or enum or enum or enum or enum or enum or enum or enum, required) — 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](/direct-executions/lifecycle#every-reason-by-family) 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`. - `status_code` (enum, required) — 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 - Allowed values: `ONGOING`, `ACTION_REQUIRED`, `COMPLETED`, `ABORTED`, `CONFIGURATION_ERROR`, `PARTIAL`, `TEMPORARY_ERROR`, `AUTH_ERROR`, `UNHANDLED_AUTH_ERROR`, `FAILED` - `execution_id` (string, optional) — The handle to this execution, and the one value worth storing from this response: you poll it for the state, you match it against the webhooks we deliver, and every results endpoint is addressed by it. **Present only when the execution was created.** A request refused before that — a collision, an invalid configuration — answers without it. - `session_id` (string, optional) — The session this execution belongs to. An execution launched on its own is its own session, so today the two values usually match — **treat them as two independent identifiers anyway**: an execution can be one step of a wider journey, and a run you are pointed at is not always the one you asked for. Address results and state by `execution_id`. Like it, this is only present when an execution was created. - `external_execution_id` (string, optional) — The reference you attached when the execution was started, if you sent one — echoed so your own identifier travels beside ours, on this response and on every event. - `status_message` (string, optional) — A human-readable note, when there is one to add. It is diagnostic and never a contract: do not parse it and do not show it to your end user as it comes — branch on `status_reason` and write your own copy. - `session_token` (string, optional) — A short-lived token that authorises **acting on this execution and nothing else**: it cannot read a single extracted record, and it stops working when the execution ends. **Resolving a pause through this API needs none of it** — collect the value and send it to the resume endpoint. The token is for the other option, which is **coming**: handing that moment to a minimal hosted interface instead of building the screens yourself. Not a [flow](/flows/overview) — no journey, no consent step, no branding, just what a pause needs over the execution you already started. Until it ships there is nothing to present this token to, so you can safely ignore it. The prefix says which kind of run issued it: `st_test_` when the run is a rehearsal — a sandbox application, or a sandbox engine under a production one — and `st_live_` otherwise. - `ticket` (string, optional) — A single-use ticket for the credentials this execution just used. It is returned **only when the execution asked for tokenized access and your application is allowed to use it**. **You see it here and nowhere else.** Exchange it for a token and it is spent: what we keep afterwards is the sealed credentials and a verifier — never the key that opens them, which is the half you hold. Keep it out of your logs, and read the [Credential Tokenization](/guides/credential-tokenization) guide for the shared-custody model behind it. ## Errors ### 400 Bad Request Error **400 Bad Request**The execution was perfectly viable — the request is complete, and a malformed one answers `422` instead. What stops it is one detail we can see BEFORE initialising anything: something that makes this run impossible, not merely likely to fail. `status_reason` says which, from the same vocabulary a finished execution uses — so your code can read a refusal exactly as it reads a failure. There is no `execution_id`, because no execution was ever created, and nothing was persisted. Two cases today: `CUSTOMER_INTERVENTION_REQUIRED`, when the engine needs a person at every run and none was declared, and `T10N_FORBIDDEN`, when the request asked for `base_configurations.tokenized_access` and the application is not enabled to tokenize. - `app_id` (string, required) — 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_id` (string, required) — 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. - `auth_origin` (enum, required) — 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. - Allowed values: `app-secret`, `user-token`, `session-token` - `engine_reference` (string, required) — 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. - `status_reason` (enum or enum or enum or enum or enum or enum or enum or enum or enum or enum, required) — 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](/direct-executions/lifecycle#every-reason-by-family) 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`. - `status_code` (enum, required) — 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 - Allowed values: `ONGOING`, `ACTION_REQUIRED`, `COMPLETED`, `ABORTED`, `CONFIGURATION_ERROR`, `PARTIAL`, `TEMPORARY_ERROR`, `AUTH_ERROR`, `UNHANDLED_AUTH_ERROR`, `FAILED` - `execution_id` (string, optional) — The handle to this execution, and the one value worth storing from this response: you poll it for the state, you match it against the webhooks we deliver, and every results endpoint is addressed by it. **Present only when the execution was created.** A request refused before that — a collision, an invalid configuration — answers without it. - `session_id` (string, optional) — The session this execution belongs to. An execution launched on its own is its own session, so today the two values usually match — **treat them as two independent identifiers anyway**: an execution can be one step of a wider journey, and a run you are pointed at is not always the one you asked for. Address results and state by `execution_id`. Like it, this is only present when an execution was created. - `external_execution_id` (string, optional) — The reference you attached when the execution was started, if you sent one — echoed so your own identifier travels beside ours, on this response and on every event. - `status_message` (string, optional) — A human-readable note, when there is one to add. It is diagnostic and never a contract: do not parse it and do not show it to your end user as it comes — branch on `status_reason` and write your own copy. - `session_token` (string, optional) — A short-lived token that authorises **acting on this execution and nothing else**: it cannot read a single extracted record, and it stops working when the execution ends. **Resolving a pause through this API needs none of it** — collect the value and send it to the resume endpoint. The token is for the other option, which is **coming**: handing that moment to a minimal hosted interface instead of building the screens yourself. Not a [flow](/flows/overview) — no journey, no consent step, no branding, just what a pause needs over the execution you already started. Until it ships there is nothing to present this token to, so you can safely ignore it. The prefix says which kind of run issued it: `st_test_` when the run is a rehearsal — a sandbox application, or a sandbox engine under a production one — and `st_live_` otherwise. - `ticket` (string, optional) — A single-use ticket for the credentials this execution just used. It is returned **only when the execution asked for tokenized access and your application is allowed to use it**. **You see it here and nowhere else.** Exchange it for a token and it is spent: what we keep afterwards is the sealed credentials and a verifier — never the key that opens them, which is the half you hold. Keep it out of your logs, and read the [Credential Tokenization](/guides/credential-tokenization) guide for the shared-custody model behind it. ### 404 Not Found Error **404 Not Found**Engine not found - `detail` (string, required) — Error message ### 409 Conflict Error **409 Conflict**Not so much a failure as a pointer: an execution matching this one is already running, and `execution_id` in the body is THAT run — follow it instead of starting another. Nothing was created here. - `app_id` (string, required) — 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_id` (string, required) — 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. - `auth_origin` (enum, required) — 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. - Allowed values: `app-secret`, `user-token`, `session-token` - `engine_reference` (string, required) — 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. - `status_reason` (enum or enum or enum or enum or enum or enum or enum or enum or enum or enum, required) — 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](/direct-executions/lifecycle#every-reason-by-family) 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`. - `status_code` (enum, required) — 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 - Allowed values: `ONGOING`, `ACTION_REQUIRED`, `COMPLETED`, `ABORTED`, `CONFIGURATION_ERROR`, `PARTIAL`, `TEMPORARY_ERROR`, `AUTH_ERROR`, `UNHANDLED_AUTH_ERROR`, `FAILED` - `execution_id` (string, optional) — The handle to this execution, and the one value worth storing from this response: you poll it for the state, you match it against the webhooks we deliver, and every results endpoint is addressed by it. **Present only when the execution was created.** A request refused before that — a collision, an invalid configuration — answers without it. - `session_id` (string, optional) — The session this execution belongs to. An execution launched on its own is its own session, so today the two values usually match — **treat them as two independent identifiers anyway**: an execution can be one step of a wider journey, and a run you are pointed at is not always the one you asked for. Address results and state by `execution_id`. Like it, this is only present when an execution was created. - `external_execution_id` (string, optional) — The reference you attached when the execution was started, if you sent one — echoed so your own identifier travels beside ours, on this response and on every event. - `status_message` (string, optional) — A human-readable note, when there is one to add. It is diagnostic and never a contract: do not parse it and do not show it to your end user as it comes — branch on `status_reason` and write your own copy. - `session_token` (string, optional) — A short-lived token that authorises **acting on this execution and nothing else**: it cannot read a single extracted record, and it stops working when the execution ends. **Resolving a pause through this API needs none of it** — collect the value and send it to the resume endpoint. The token is for the other option, which is **coming**: handing that moment to a minimal hosted interface instead of building the screens yourself. Not a [flow](/flows/overview) — no journey, no consent step, no branding, just what a pause needs over the execution you already started. Until it ships there is nothing to present this token to, so you can safely ignore it. The prefix says which kind of run issued it: `st_test_` when the run is a rehearsal — a sandbox application, or a sandbox engine under a production one — and `st_live_` otherwise. - `ticket` (string, optional) — A single-use ticket for the credentials this execution just used. It is returned **only when the execution asked for tokenized access and your application is allowed to use it**. **You see it here and nowhere else.** Exchange it for a token and it is spent: what we keep afterwards is the sealed credentials and a verifier — never the key that opens them, which is the half you hold. Keep it out of your logs, and read the [Credential Tokenization](/guides/credential-tokenization) guide for the shared-custody model behind it. ### 422 Unprocessable Entity Error **422 Unprocessable Content**The request could not be read: a field is missing, has the wrong type, or carries a value the schema refuses — a date range wider than the engine allows, a duplicated feature, a value that does not decrypt. `detail` names every offender by its path in the body, so the message points at the field rather than at the request. Nothing was created: this is the answer BEFORE any of the checks that could reject a well-formed request with a `400`. - `detail` (list of object, required) - `loc` (list of string or integer, required) - `msg` (string, required) - `type` (string, required) - `input` (any, optional) - `ctx` (object, optional) ### 503 Service Unavailable Error **503 Service Unavailable**The engine cannot run this, and it is not your request. `detail` says which case, and they are not all temporary: * `engine_is_under_maintenance`, `engine_has_no_release_candidate_yet`, `engine_not_deployed` — transient. Retry later. * `engine_is_draft`, `engine_is_under_development`, `engine_is_archived`, `engine_is_locked` — the engine is not open for use. Retrying changes nothing. * `engine_not_available_for_sandbox_apps`, `engine_not_available_for_current_company` — it exists, but not for this application. [List Engines](api:GET/config/engines/list) only ever returns what you may run right now, which is why building from the catalogue avoids this answer entirely. - `detail` (string, required) — Error message ## Examples ### Demo Bank (sandbox) **Request** ```json { "engine_reference": "DEMOBANKXXXXFIN100ES9999-mobile", "customer_id": "my-customer-1", "parameters": { "password": "1234", "use_case": "Normal Execution", "username": "adler.marmol@example.com" }, "base_configurations": { "customer_interaction_available": false, "tokenized_access": false }, "features": [ { "code": "customer_information_read" }, { "code": "accounts_read", "configurations": { "from_date": "30 days ago", "to_date": "today", "read_transactions": true, "read_holders": true } }, { "code": "cards_read", "configurations": { "from_date": "30 days ago", "to_date": "today", "read_transactions": true } }, { "code": "loans_read" } ] } ``` **Response** ```json { "app_id": "4aa3dcbab3287e2385bb5cec", "customer_id": "my-customer-1", "auth_origin": "app-secret", "engine_reference": "DEMOBANKXXXXFIN100ES9999-mobile", "status_reason": "ACCEPTED", "status_code": "ONGOING", "execution_id": "6aa3d8b418d1c5dc9a8e3d36", "session_id": "5aa3dca503e37e6809539a58", "external_execution_id": "case-A-1029", "session_token": "st_live_H6rhkDOx5XoAjtyW.A7kcIRNaDK6TMYijuiTu", "ticket": "ibAeHHRvLpc2tKVM1FbXXOkups1zADyRhcsLc5gb3EycOM61j1QzLTD5cWGJ8EDM" } ``` **SDK Code** ```python Demo Bank (sandbox) import requests url = "https://clients.infonite.tech/api/executions/init/v1/parametrized" payload = { "engine_reference": "DEMOBANKXXXXFIN100ES9999-mobile", "customer_id": "my-customer-1", "parameters": { "password": "1234", "use_case": "Normal Execution", "username": "adler.marmol@example.com" }, "base_configurations": { "customer_interaction_available": False, "tokenized_access": False }, "features": [{ "code": "customer_information_read" }, { "code": "accounts_read", "configurations": { "from_date": "30 days ago", "to_date": "today", "read_transactions": True, "read_holders": True } }, { "code": "cards_read", "configurations": { "from_date": "30 days ago", "to_date": "today", "read_transactions": True } }, { "code": "loans_read" }] } headers = { "X-APP-SECRET": "", "Content-Type": "application/json" } response = requests.post(url, json=payload, headers=headers) print(response.json()) ``` ```javascript Demo Bank (sandbox) const url = 'https://clients.infonite.tech/api/executions/init/v1/parametrized'; const options = { method: 'POST', headers: {'X-APP-SECRET': '', 'Content-Type': 'application/json'}, body: '{"engine_reference":"DEMOBANKXXXXFIN100ES9999-mobile","customer_id":"my-customer-1","parameters":{"password":"1234","use_case":"Normal Execution","username":"adler.marmol@example.com"},"base_configurations":{"customer_interaction_available":false,"tokenized_access":false},"features":[{"code":"customer_information_read"},{"code":"accounts_read","configurations":{"from_date":"30 days ago","to_date":"today","read_transactions":true,"read_holders":true}},{"code":"cards_read","configurations":{"from_date":"30 days ago","to_date":"today","read_transactions":true}},{"code":"loans_read"}]}' }; try { const response = await fetch(url, options); const data = await response.json(); console.log(data); } catch (error) { console.error(error); } ``` ```go Demo Bank (sandbox) package main import ( "fmt" "strings" "net/http" "io" ) func main() { url := "https://clients.infonite.tech/api/executions/init/v1/parametrized" payload := strings.NewReader("{\n \"engine_reference\": \"DEMOBANKXXXXFIN100ES9999-mobile\",\n \"customer_id\": \"my-customer-1\",\n \"parameters\": {\n \"password\": \"1234\",\n \"use_case\": \"Normal Execution\",\n \"username\": \"adler.marmol@example.com\"\n },\n \"base_configurations\": {\n \"customer_interaction_available\": false,\n \"tokenized_access\": false\n },\n \"features\": [\n {\n \"code\": \"customer_information_read\"\n },\n {\n \"code\": \"accounts_read\",\n \"configurations\": {\n \"from_date\": \"30 days ago\",\n \"to_date\": \"today\",\n \"read_transactions\": true,\n \"read_holders\": true\n }\n },\n {\n \"code\": \"cards_read\",\n \"configurations\": {\n \"from_date\": \"30 days ago\",\n \"to_date\": \"today\",\n \"read_transactions\": true\n }\n },\n {\n \"code\": \"loans_read\"\n }\n ]\n}") req, _ := http.NewRequest("POST", url, payload) req.Header.Add("X-APP-SECRET", "") req.Header.Add("Content-Type", "application/json") res, _ := http.DefaultClient.Do(req) defer res.Body.Close() body, _ := io.ReadAll(res.Body) fmt.Println(res) fmt.Println(string(body)) } ``` ```ruby Demo Bank (sandbox) require 'uri' require 'net/http' url = URI("https://clients.infonite.tech/api/executions/init/v1/parametrized") http = Net::HTTP.new(url.host, url.port) http.use_ssl = true request = Net::HTTP::Post.new(url) request["X-APP-SECRET"] = '' request["Content-Type"] = 'application/json' request.body = "{\n \"engine_reference\": \"DEMOBANKXXXXFIN100ES9999-mobile\",\n \"customer_id\": \"my-customer-1\",\n \"parameters\": {\n \"password\": \"1234\",\n \"use_case\": \"Normal Execution\",\n \"username\": \"adler.marmol@example.com\"\n },\n \"base_configurations\": {\n \"customer_interaction_available\": false,\n \"tokenized_access\": false\n },\n \"features\": [\n {\n \"code\": \"customer_information_read\"\n },\n {\n \"code\": \"accounts_read\",\n \"configurations\": {\n \"from_date\": \"30 days ago\",\n \"to_date\": \"today\",\n \"read_transactions\": true,\n \"read_holders\": true\n }\n },\n {\n \"code\": \"cards_read\",\n \"configurations\": {\n \"from_date\": \"30 days ago\",\n \"to_date\": \"today\",\n \"read_transactions\": true\n }\n },\n {\n \"code\": \"loans_read\"\n }\n ]\n}" response = http.request(request) puts response.read_body ``` ```java Demo Bank (sandbox) import com.mashape.unirest.http.HttpResponse; import com.mashape.unirest.http.Unirest; HttpResponse response = Unirest.post("https://clients.infonite.tech/api/executions/init/v1/parametrized") .header("X-APP-SECRET", "") .header("Content-Type", "application/json") .body("{\n \"engine_reference\": \"DEMOBANKXXXXFIN100ES9999-mobile\",\n \"customer_id\": \"my-customer-1\",\n \"parameters\": {\n \"password\": \"1234\",\n \"use_case\": \"Normal Execution\",\n \"username\": \"adler.marmol@example.com\"\n },\n \"base_configurations\": {\n \"customer_interaction_available\": false,\n \"tokenized_access\": false\n },\n \"features\": [\n {\n \"code\": \"customer_information_read\"\n },\n {\n \"code\": \"accounts_read\",\n \"configurations\": {\n \"from_date\": \"30 days ago\",\n \"to_date\": \"today\",\n \"read_transactions\": true,\n \"read_holders\": true\n }\n },\n {\n \"code\": \"cards_read\",\n \"configurations\": {\n \"from_date\": \"30 days ago\",\n \"to_date\": \"today\",\n \"read_transactions\": true\n }\n },\n {\n \"code\": \"loans_read\"\n }\n ]\n}") .asString(); ``` ```php Demo Bank (sandbox) request('POST', 'https://clients.infonite.tech/api/executions/init/v1/parametrized', [ 'body' => '{ "engine_reference": "DEMOBANKXXXXFIN100ES9999-mobile", "customer_id": "my-customer-1", "parameters": { "password": "1234", "use_case": "Normal Execution", "username": "adler.marmol@example.com" }, "base_configurations": { "customer_interaction_available": false, "tokenized_access": false }, "features": [ { "code": "customer_information_read" }, { "code": "accounts_read", "configurations": { "from_date": "30 days ago", "to_date": "today", "read_transactions": true, "read_holders": true } }, { "code": "cards_read", "configurations": { "from_date": "30 days ago", "to_date": "today", "read_transactions": true } }, { "code": "loans_read" } ] }', 'headers' => [ 'Content-Type' => 'application/json', 'X-APP-SECRET' => '', ], ]); echo $response->getBody(); ``` ```csharp Demo Bank (sandbox) using RestSharp; var client = new RestClient("https://clients.infonite.tech/api/executions/init/v1/parametrized"); var request = new RestRequest(Method.POST); request.AddHeader("X-APP-SECRET", ""); request.AddHeader("Content-Type", "application/json"); request.AddParameter("application/json", "{\n \"engine_reference\": \"DEMOBANKXXXXFIN100ES9999-mobile\",\n \"customer_id\": \"my-customer-1\",\n \"parameters\": {\n \"password\": \"1234\",\n \"use_case\": \"Normal Execution\",\n \"username\": \"adler.marmol@example.com\"\n },\n \"base_configurations\": {\n \"customer_interaction_available\": false,\n \"tokenized_access\": false\n },\n \"features\": [\n {\n \"code\": \"customer_information_read\"\n },\n {\n \"code\": \"accounts_read\",\n \"configurations\": {\n \"from_date\": \"30 days ago\",\n \"to_date\": \"today\",\n \"read_transactions\": true,\n \"read_holders\": true\n }\n },\n {\n \"code\": \"cards_read\",\n \"configurations\": {\n \"from_date\": \"30 days ago\",\n \"to_date\": \"today\",\n \"read_transactions\": true\n }\n },\n {\n \"code\": \"loans_read\"\n }\n ]\n}", ParameterType.RequestBody); IRestResponse response = client.Execute(request); ``` ```swift Demo Bank (sandbox) import Foundation let headers = [ "X-APP-SECRET": "", "Content-Type": "application/json" ] let parameters = [ "engine_reference": "DEMOBANKXXXXFIN100ES9999-mobile", "customer_id": "my-customer-1", "parameters": [ "password": "1234", "use_case": "Normal Execution", "username": "adler.marmol@example.com" ], "base_configurations": [ "customer_interaction_available": false, "tokenized_access": false ], "features": [["code": "customer_information_read"], [ "code": "accounts_read", "configurations": [ "from_date": "30 days ago", "to_date": "today", "read_transactions": true, "read_holders": true ] ], [ "code": "cards_read", "configurations": [ "from_date": "30 days ago", "to_date": "today", "read_transactions": true ] ], ["code": "loans_read"]] ] as [String : Any] let postData = JSONSerialization.data(withJSONObject: parameters, options: []) let request = NSMutableURLRequest(url: NSURL(string: "https://clients.infonite.tech/api/executions/init/v1/parametrized")! as URL, cachePolicy: .useProtocolCachePolicy, timeoutInterval: 10.0) request.httpMethod = "POST" request.allHTTPHeaderFields = headers request.httpBody = postData as Data let session = URLSession.shared let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in if (error != nil) { print(error as Any) } else { let httpResponse = response as? HTTPURLResponse print(httpResponse) } }) dataTask.resume() ``` ### Demo Social Security (sandbox) **Request** ```json { "engine_reference": "TGSSXSBXXXXXPUB254ESXXXX-api", "customer_id": "my-customer-1", "parameters": { "age": 55, "debt_level": "Poco", "has_driving_permit": true, "has_vehicles": true, "income_level": "Ingresos promedio", "is_limited": false, "is_widowed": false, "marital_status": "Soltero", "nationality": "ES", "work_status": "Empleado / Tiempo completo" }, "base_configurations": { "customer_interaction_available": true }, "features": [ { "code": "customer_information_read" }, { "code": "labor_check" }, { "code": "public_pensions" }, { "code": "driver_data", "configurations": { "read_point_movements": true } }, { "code": "vehicles_data", "configurations": { "simple_vehicle_report": true } }, { "code": "credit_registry_data", "configurations": { "preferred_type": "credit_registry_data:es_cirbe_detailed" } } ], "hooks_extra_data": { "current_event": "{event}", "id_operacion": "case-A-1029", "status": "{status_reason}" } } ``` **Response** ```json { "app_id": "4aa3dcbab3287e2385bb5cec", "customer_id": "my-customer-1", "auth_origin": "app-secret", "engine_reference": "TGSSXSBXXXXXPUB254ESXXXX-api", "status_reason": "ACCEPTED", "status_code": "ONGOING", "execution_id": "6aa3d8b418d1c5dc9a8e3d36", "session_id": "5aa3dca503e37e6809539a58", "external_execution_id": "case-A-1029", "session_token": "st_live_H6rhkDOx5XoAjtyW.A7kcIRNaDK6TMYijuiTu" } ``` **SDK Code** ```python Demo Social Security (sandbox) import requests url = "https://clients.infonite.tech/api/executions/init/v1/parametrized" payload = { "engine_reference": "TGSSXSBXXXXXPUB254ESXXXX-api", "customer_id": "my-customer-1", "parameters": { "age": 55, "debt_level": "Poco", "has_driving_permit": True, "has_vehicles": True, "income_level": "Ingresos promedio", "is_limited": False, "is_widowed": False, "marital_status": "Soltero", "nationality": "ES", "work_status": "Empleado / Tiempo completo" }, "base_configurations": { "customer_interaction_available": True }, "features": [ { "code": "customer_information_read" }, { "code": "labor_check" }, { "code": "public_pensions" }, { "code": "driver_data", "configurations": { "read_point_movements": True } }, { "code": "vehicles_data", "configurations": { "simple_vehicle_report": True } }, { "code": "credit_registry_data", "configurations": { "preferred_type": "credit_registry_data:es_cirbe_detailed" } } ], "hooks_extra_data": { "current_event": "{event}", "id_operacion": "case-A-1029", "status": "{status_reason}" } } headers = { "X-APP-SECRET": "", "Content-Type": "application/json" } response = requests.post(url, json=payload, headers=headers) print(response.json()) ``` ```javascript Demo Social Security (sandbox) const url = 'https://clients.infonite.tech/api/executions/init/v1/parametrized'; const options = { method: 'POST', headers: {'X-APP-SECRET': '', 'Content-Type': 'application/json'}, body: '{"engine_reference":"TGSSXSBXXXXXPUB254ESXXXX-api","customer_id":"my-customer-1","parameters":{"age":55,"debt_level":"Poco","has_driving_permit":true,"has_vehicles":true,"income_level":"Ingresos promedio","is_limited":false,"is_widowed":false,"marital_status":"Soltero","nationality":"ES","work_status":"Empleado / Tiempo completo"},"base_configurations":{"customer_interaction_available":true},"features":[{"code":"customer_information_read"},{"code":"labor_check"},{"code":"public_pensions"},{"code":"driver_data","configurations":{"read_point_movements":true}},{"code":"vehicles_data","configurations":{"simple_vehicle_report":true}},{"code":"credit_registry_data","configurations":{"preferred_type":"credit_registry_data:es_cirbe_detailed"}}],"hooks_extra_data":{"current_event":"{event}","id_operacion":"case-A-1029","status":"{status_reason}"}}' }; try { const response = await fetch(url, options); const data = await response.json(); console.log(data); } catch (error) { console.error(error); } ``` ```go Demo Social Security (sandbox) package main import ( "fmt" "strings" "net/http" "io" ) func main() { url := "https://clients.infonite.tech/api/executions/init/v1/parametrized" payload := strings.NewReader("{\n \"engine_reference\": \"TGSSXSBXXXXXPUB254ESXXXX-api\",\n \"customer_id\": \"my-customer-1\",\n \"parameters\": {\n \"age\": 55,\n \"debt_level\": \"Poco\",\n \"has_driving_permit\": true,\n \"has_vehicles\": true,\n \"income_level\": \"Ingresos promedio\",\n \"is_limited\": false,\n \"is_widowed\": false,\n \"marital_status\": \"Soltero\",\n \"nationality\": \"ES\",\n \"work_status\": \"Empleado / Tiempo completo\"\n },\n \"base_configurations\": {\n \"customer_interaction_available\": true\n },\n \"features\": [\n {\n \"code\": \"customer_information_read\"\n },\n {\n \"code\": \"labor_check\"\n },\n {\n \"code\": \"public_pensions\"\n },\n {\n \"code\": \"driver_data\",\n \"configurations\": {\n \"read_point_movements\": true\n }\n },\n {\n \"code\": \"vehicles_data\",\n \"configurations\": {\n \"simple_vehicle_report\": true\n }\n },\n {\n \"code\": \"credit_registry_data\",\n \"configurations\": {\n \"preferred_type\": \"credit_registry_data:es_cirbe_detailed\"\n }\n }\n ],\n \"hooks_extra_data\": {\n \"current_event\": \"{event}\",\n \"id_operacion\": \"case-A-1029\",\n \"status\": \"{status_reason}\"\n }\n}") req, _ := http.NewRequest("POST", url, payload) req.Header.Add("X-APP-SECRET", "") req.Header.Add("Content-Type", "application/json") res, _ := http.DefaultClient.Do(req) defer res.Body.Close() body, _ := io.ReadAll(res.Body) fmt.Println(res) fmt.Println(string(body)) } ``` ```ruby Demo Social Security (sandbox) require 'uri' require 'net/http' url = URI("https://clients.infonite.tech/api/executions/init/v1/parametrized") http = Net::HTTP.new(url.host, url.port) http.use_ssl = true request = Net::HTTP::Post.new(url) request["X-APP-SECRET"] = '' request["Content-Type"] = 'application/json' request.body = "{\n \"engine_reference\": \"TGSSXSBXXXXXPUB254ESXXXX-api\",\n \"customer_id\": \"my-customer-1\",\n \"parameters\": {\n \"age\": 55,\n \"debt_level\": \"Poco\",\n \"has_driving_permit\": true,\n \"has_vehicles\": true,\n \"income_level\": \"Ingresos promedio\",\n \"is_limited\": false,\n \"is_widowed\": false,\n \"marital_status\": \"Soltero\",\n \"nationality\": \"ES\",\n \"work_status\": \"Empleado / Tiempo completo\"\n },\n \"base_configurations\": {\n \"customer_interaction_available\": true\n },\n \"features\": [\n {\n \"code\": \"customer_information_read\"\n },\n {\n \"code\": \"labor_check\"\n },\n {\n \"code\": \"public_pensions\"\n },\n {\n \"code\": \"driver_data\",\n \"configurations\": {\n \"read_point_movements\": true\n }\n },\n {\n \"code\": \"vehicles_data\",\n \"configurations\": {\n \"simple_vehicle_report\": true\n }\n },\n {\n \"code\": \"credit_registry_data\",\n \"configurations\": {\n \"preferred_type\": \"credit_registry_data:es_cirbe_detailed\"\n }\n }\n ],\n \"hooks_extra_data\": {\n \"current_event\": \"{event}\",\n \"id_operacion\": \"case-A-1029\",\n \"status\": \"{status_reason}\"\n }\n}" response = http.request(request) puts response.read_body ``` ```java Demo Social Security (sandbox) import com.mashape.unirest.http.HttpResponse; import com.mashape.unirest.http.Unirest; HttpResponse response = Unirest.post("https://clients.infonite.tech/api/executions/init/v1/parametrized") .header("X-APP-SECRET", "") .header("Content-Type", "application/json") .body("{\n \"engine_reference\": \"TGSSXSBXXXXXPUB254ESXXXX-api\",\n \"customer_id\": \"my-customer-1\",\n \"parameters\": {\n \"age\": 55,\n \"debt_level\": \"Poco\",\n \"has_driving_permit\": true,\n \"has_vehicles\": true,\n \"income_level\": \"Ingresos promedio\",\n \"is_limited\": false,\n \"is_widowed\": false,\n \"marital_status\": \"Soltero\",\n \"nationality\": \"ES\",\n \"work_status\": \"Empleado / Tiempo completo\"\n },\n \"base_configurations\": {\n \"customer_interaction_available\": true\n },\n \"features\": [\n {\n \"code\": \"customer_information_read\"\n },\n {\n \"code\": \"labor_check\"\n },\n {\n \"code\": \"public_pensions\"\n },\n {\n \"code\": \"driver_data\",\n \"configurations\": {\n \"read_point_movements\": true\n }\n },\n {\n \"code\": \"vehicles_data\",\n \"configurations\": {\n \"simple_vehicle_report\": true\n }\n },\n {\n \"code\": \"credit_registry_data\",\n \"configurations\": {\n \"preferred_type\": \"credit_registry_data:es_cirbe_detailed\"\n }\n }\n ],\n \"hooks_extra_data\": {\n \"current_event\": \"{event}\",\n \"id_operacion\": \"case-A-1029\",\n \"status\": \"{status_reason}\"\n }\n}") .asString(); ``` ```php Demo Social Security (sandbox) request('POST', 'https://clients.infonite.tech/api/executions/init/v1/parametrized', [ 'body' => '{ "engine_reference": "TGSSXSBXXXXXPUB254ESXXXX-api", "customer_id": "my-customer-1", "parameters": { "age": 55, "debt_level": "Poco", "has_driving_permit": true, "has_vehicles": true, "income_level": "Ingresos promedio", "is_limited": false, "is_widowed": false, "marital_status": "Soltero", "nationality": "ES", "work_status": "Empleado / Tiempo completo" }, "base_configurations": { "customer_interaction_available": true }, "features": [ { "code": "customer_information_read" }, { "code": "labor_check" }, { "code": "public_pensions" }, { "code": "driver_data", "configurations": { "read_point_movements": true } }, { "code": "vehicles_data", "configurations": { "simple_vehicle_report": true } }, { "code": "credit_registry_data", "configurations": { "preferred_type": "credit_registry_data:es_cirbe_detailed" } } ], "hooks_extra_data": { "current_event": "{event}", "id_operacion": "case-A-1029", "status": "{status_reason}" } }', 'headers' => [ 'Content-Type' => 'application/json', 'X-APP-SECRET' => '', ], ]); echo $response->getBody(); ``` ```csharp Demo Social Security (sandbox) using RestSharp; var client = new RestClient("https://clients.infonite.tech/api/executions/init/v1/parametrized"); var request = new RestRequest(Method.POST); request.AddHeader("X-APP-SECRET", ""); request.AddHeader("Content-Type", "application/json"); request.AddParameter("application/json", "{\n \"engine_reference\": \"TGSSXSBXXXXXPUB254ESXXXX-api\",\n \"customer_id\": \"my-customer-1\",\n \"parameters\": {\n \"age\": 55,\n \"debt_level\": \"Poco\",\n \"has_driving_permit\": true,\n \"has_vehicles\": true,\n \"income_level\": \"Ingresos promedio\",\n \"is_limited\": false,\n \"is_widowed\": false,\n \"marital_status\": \"Soltero\",\n \"nationality\": \"ES\",\n \"work_status\": \"Empleado / Tiempo completo\"\n },\n \"base_configurations\": {\n \"customer_interaction_available\": true\n },\n \"features\": [\n {\n \"code\": \"customer_information_read\"\n },\n {\n \"code\": \"labor_check\"\n },\n {\n \"code\": \"public_pensions\"\n },\n {\n \"code\": \"driver_data\",\n \"configurations\": {\n \"read_point_movements\": true\n }\n },\n {\n \"code\": \"vehicles_data\",\n \"configurations\": {\n \"simple_vehicle_report\": true\n }\n },\n {\n \"code\": \"credit_registry_data\",\n \"configurations\": {\n \"preferred_type\": \"credit_registry_data:es_cirbe_detailed\"\n }\n }\n ],\n \"hooks_extra_data\": {\n \"current_event\": \"{event}\",\n \"id_operacion\": \"case-A-1029\",\n \"status\": \"{status_reason}\"\n }\n}", ParameterType.RequestBody); IRestResponse response = client.Execute(request); ``` ```swift Demo Social Security (sandbox) import Foundation let headers = [ "X-APP-SECRET": "", "Content-Type": "application/json" ] let parameters = [ "engine_reference": "TGSSXSBXXXXXPUB254ESXXXX-api", "customer_id": "my-customer-1", "parameters": [ "age": 55, "debt_level": "Poco", "has_driving_permit": true, "has_vehicles": true, "income_level": "Ingresos promedio", "is_limited": false, "is_widowed": false, "marital_status": "Soltero", "nationality": "ES", "work_status": "Empleado / Tiempo completo" ], "base_configurations": ["customer_interaction_available": true], "features": [ ["code": "customer_information_read"], ["code": "labor_check"], ["code": "public_pensions"], [ "code": "driver_data", "configurations": ["read_point_movements": true] ], [ "code": "vehicles_data", "configurations": ["simple_vehicle_report": true] ], [ "code": "credit_registry_data", "configurations": ["preferred_type": "credit_registry_data:es_cirbe_detailed"] ] ], "hooks_extra_data": [ "current_event": "{event}", "id_operacion": "case-A-1029", "status": "{status_reason}" ] ] as [String : Any] let postData = JSONSerialization.data(withJSONObject: parameters, options: []) let request = NSMutableURLRequest(url: NSURL(string: "https://clients.infonite.tech/api/executions/init/v1/parametrized")! as URL, cachePolicy: .useProtocolCachePolicy, timeoutInterval: 10.0) request.httpMethod = "POST" request.allHTTPHeaderFields = headers request.httpBody = postData as Data let session = URLSession.shared let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in if (error != nil) { print(error as Any) } else { let httpResponse = response as? HTTPURLResponse print(httpResponse) } }) dataTask.resume() ```