Verification
API Action & Merge
Call an external API from the middle of a workflow — one call per step — write what it returns into the workflow's variables, and join branches back together with a Merge.
An API Action is a workflow step that makes exactly one outbound HTTP or HTTPS call to a partner API, then writes the values you extract from the response into the workflow's variables — so later steps, Conditions and the next questionnaire can use them in the same verification. A Merge joins two or more branches back into one path.
Info
API Action is a platform feature that is off by default. Your ThirdFactor account manager enables it for your organisation (it also unlocks the Merge, Condition and External routing steps) and allowlists the domains or IPs your calls may reach. Both steps live in the Advanced workflow builder.
How it runs
- The step runs server-side, as soon as every step before it has finished — by the same rule as a Condition, so an API Action right after a Condition runs in the same step the Condition is decided in. Background checks (AML screening, Device & IP, age estimation) don't hold it up unless it reads one of their values: an API Action that reads the AML risk level waits for AML. The applicant never waits on a screen unless the step shows a result card.
- One call per run. Retries (Reliability tab) repeat the same call; to call two APIs, add two API Actions — and join them with a Merge to consolidate their values.
- Every run is billed at your API Action rate when the call leaves the platform. A call refused before it is made (endpoint not allowlisted, private address, feature off) is free and holds the verification for review.
Configuring the call
The editor is the same one questionnaire actions use — Trigger · Request · Auth · Reliability · Response · Display · Try it:
| Tab | What you set |
|---|---|
| Trigger | The step's name, what a failed call does (continue with the values unset, hold for review, or decline), and optionally a Marketplace template or a questionnaire action to convert |
| Request | Method, http:// or https:// endpoint, query parameters, headers and body. Any value produced upstream can be pulled in with the variable picker: {{vars.<step>.<field>}} |
| Auth | API key, bearer token, basic, custom headers, OAuth2 client credentials or mTLS — credentials are picked from your organisation's shared vault, never typed into the step |
| Reliability | Retries, what counts as success, response size |
| Response | Write to workflow variables — JSON paths into the response, array indexing included ($.response[0].Result, $.response.items[-1].id, $.response.rows[*].code) |
| Display | An optional card (summary card, information panel / notice, status badge, table) shown on this step or at the top of the immediately next step when it is a Questionnaire — never further away |
Workflow variables
Every step exposes typed variables (<node_id>.<field>) to the steps after it: questionnaire answers (QUESTIONNAIRE.answers.<field_id>), ID fields (ID_VERIFICATION.document_number, …date_of_birth, …is_minor), liveness and face-match scores, AML risk (AML_SCREENING.risk_level), the chosen product or branch, an API Action's extracted values, and session-level values such as session.risk_score. A value is unset until its step has run — or when its branch was not taken, or its call failed — and only an is not set rule matches it.
Network safety
Calls may go to any allowlisted domain, subdomain or raw IP, over HTTP or HTTPS. Private, loopback and link-local addresses (RFC 1918, 127.0.0.0/8, 169.254.0.0/16, CGNAT, IPv6 ULA / link-local) are refused by default; your account manager can grant your organisation a specific private range. Cloud-metadata addresses are never reachable. Every redirect is re-checked, and an https → http downgrade is refused.
Marketplace templates
A connected Marketplace provider's lookups (for example Pumori · Account Validation) can be added as a pre-filled API Action: the request shape, sign-in and a response mapping come from the provider; you map its inputs to earlier steps' values. It runs on the same engine, with your provider connection's own credentials.
Results
Each run is one entry in the session's decision_v3.api_actions (and the webhook decision): action_name, method, endpoint (no query string), ok, response_status, elapsed_ms, outputs — the extracted values — and billable. Credentials never appear. The verification's timeline records every execution, and the full masked request / response audit is on the verification's Form actions tab.
Questionnaire actions
Actions embedded in a questionnaire keep running unchanged, but are deprecated: new integrations belong in an API Action step. To move one, add an API Action after the questionnaire and choose Convert a questionnaire action — the step is pre-filled from it, answers are re-pointed at the questionnaire's variables, and anything a step cannot do (prefilling, show / hide, progression gates) is listed for you.