Financial Rider gets its reference, and every run stays in its own environment

Financial Rider has its public reference. Create a session from your backend — naming the markets and kinds of bank your customer may choose from, or the one bank to connect —, send your customer to the widget, and read one financial position merged from every bank they connected, up to three per session: accounts, cards, deposits, loans, investments and direct debits, in the same shape direct executions return.

Three webhooks tell your backend what happened: financial-rider:started, financial-rider:consent and financial-rider:ended. Their data travels only encrypted, with the key the session was created with; without one, each event is a notification and the results are read over the API. Webhooks.
A bank that turns the credentials down is never taken away. Your customer is warned before trying it again, so they do not lock their own access, and decides.
One-shot or recurring access. A session reads your customer’s banks once — or, with recurring access, your customer connects once in the widget and your backend refreshes those banks afterwards, without them, through the direct executions API. Built for bank reconciliation, money management and monitoring: Recurring Access.
Where your customer lands when they are done is yours to choose, exactly as in Spain Public Administration: Redirects & Completion.

The endpoints, the schemas and the events are in the Financial Rider API reference.

Spain Public Administration: a production session needs the product enabled

A production session of Spain Public Administration now requires the application to be enabled for the product, exactly as Financial Rider’s does: without it, Create Session answers 403 insufficient_capabilities@product:es_public_administration. Every application already running the flow in production has been enabled before this went live; a sandbox session needs nothing.

Sandbox and production never mix

A widget session runs engines of its own environment only. A sandbox session never opens a real institution (503 engine_not_available_for_sandbox_sessions), and a production session never opens a demo engine (503 engine_not_available_for_production_sessions), so nothing a production session returns comes from a demo.
The engine catalogue of direct executions lists one environment, the one you ask for: List your engines takes environment — production or sandbox, by default your application’s. A production application may list the sandbox engines to rehearse with; a sandbox application lists sandbox engines only, and asking it for production answers 403 production_not_enabled_for_this_app.
A sandbox application is refused a real institution with engine_not_available_for_sandbox_apps. engine_not_available_for_current_company no longer exists: nothing restricts an engine by company.
An engine that is still being built is neither listed nor launched, for any application.

An engine alternative is named, never numbered. An engine_reference ends in the alternative’s name — website, mobile, api or other —, and a number in its place (0 to 3, or a reference ending in -1) is refused as invalid. Take the references from List your engines, which returns them named.

Downloading attachments: the answers it really gives

The attachment download of the widget flows documents exactly what it answers — 401 and 403 for the application secret, 404 for a session or a document that is not yours, 422 for an id that is not one, and 429 past one download every 5 seconds per document. It never answered 202 nor 412, which its page used to list: a handler written for them can go. It is published in the Financial Rider reference too, for the receipts a bank keeps with a direct debit.

Changelog