Skip to navigation

Platform updates and API changelog for INFONITE

Direct Executions — your customer answers the second factor, and the product is granted per application

INFONITE’s widget, for a run you started

A direct execution started with base_configurations.customer_interaction_available: true now answers with a widget_url — from Initiate with parameters and Initiate with a token alike. Open it for your customer — a redirect, a new tab or, once your site’s origin is enabled, an iframe of your page (Opening it) — and INFONITE’s widget takes care of them for that one run, in your application’s colours: its progress, the code or confirmation the institution asks for, how it ended, and the way back to the completion_url you set. Nothing to build. Or keep your own screens: the run is still yours to follow, answer with Answer and resume, read and delete. Inside an iframe it tells your page how it ended, with a direct-execution:ended message. Challenges & MFA explains it.

It fits Financial Rider’s recurring access too: when your customer refreshes a tokenized connection from your app and the bank asks for a second factor again, they answer it in the widget, with no new session — Refreshing with your customer present. In production a refresh is a direct execution, so it needs product:direct_executions as well as login:tokenized_access (below).

A way back you add to the widget’s URL

Append completion_url — and, if you like, completion_mode — to a widget_url and the widget’s final screen takes your customer there, in this tab, a new one or behind a button. It works for direct executions and for any Financial Rider or Spain Public Administration session created without a way back of its own (the session’s always wins), and only to an address under one of your application’s redirect URLs, checked when the widget reaches its final screen. Redirects & Completion explains it.

A direct execution’s session_token — the one inside its widget_url — can now be replaced or revoked from your backend: Issue a session token answers a new token and link, and the old link opens nothing from that moment; Revoke the session token leaves no link that opens the execution. The execution itself is untouched either way. Your customer’s session token explains how long it lasts and what it opens.

The same, for Financial Rider and Spain Public Administration: a session’s widget token can be replaced — Issue a Session Token answers a new token and widget_url, and the old link opens nothing from that moment — or revoked, from your backend with your application secret. A session’s token lives as long as the session, never shorter for not being used; deleting the session leaves it for the person still on its last screen — revoke it, before or after the deletion, when a link must stop working.

Production runs need Direct Executions

Direct Executions is a product your application holds, like the flows. A production run now needs the capability product:direct_executions; without it both ways in answer 403 with insufficient_capabilities@product:direct_executions and nothing is created. A sandbox run never needs it. Capabilities says how to have it granted.