Linked Journey (JSR) — single-redirect data consent and enrollment

The Linked Journey (JSR) creates the Open Finance data consent and the JSR enrollment in a single API call, so the payer authenticates once at the account holder instead of going through two separate journeys.

Before this journey existed, offering a JSR (redirectless) payment with account visibility meant running a data-sharing journey (to read accounts and balances) and an enrollment journey (to open the payment vínculo) — two redirects, two authorisations, two sets of identifiers to reconcile. Here a single POST /api/v1/linked-journey/jsr returns one redirectUrl, and after the payer approves it you can read both the shared account data and continue the enrollment exactly like a normal JSR (Redirectless) flow.

What a single call does

The API performs these steps server-side before responding:

1. Creates the data consent at Data Link (POST /api/v1/consents) with a fixed permission set defined by the server.
2. Reads the created consent back to obtain the Data Link userId.
3. Creates the JSR enrollment at the account holder, attaching the data consent to the request via the journey field.
4. Returns redirectUrl (for the holder redirect) and dataConsentId.

Prerequisites

1. Obtain an OAuth 2.0 access token as described in Get your credentials. Every route in this journey requires the role epp-user or epp-sub-tenants.
2. Complete Onboarding so redirect domains are allow-listed for your sub-tenant.
3. Call Get registered participants (or Get most used participants) so the payer can choose an institution — this is where the organisationId and authorisationServerId required by this journey come from.

Stage 0 — Create the journey and redirect the payer

1. Call Create optimized binding with organisationId, authorisationServerId, enrollment, and riskSignals — the same contract as a plain Create enrollment call.
2. From 201 Created, persist data.id (the enrollment id), data.dataConsentId, and data.flowId server-side.
3. Send the payer to data.redirectUrl to authenticate and approve both the data consent and the enrollment at the account holder.
4. After approval, the holder redirects the browser to the redirectUri you sent. That URL must be owned and operated by your application (allow-listed on the sub-tenant); Lina does not host it. Your callback page must parse the URL fragment for code, state, and id_token.

Stage 1 — Retrieve the consent and the payer accounts

1. Call Get data consent with the dataConsentId you stored, until data.status is AUTHORISED. Read data.userId from the response.
2. Call Get user accounts with that userId to list the payer accounts, balances, and details — use them to let the payer pick the account the JSR payment will debit.

Stage 2 — Continue the JSR payment flow

From here on, the enrollment behaves exactly like one created through the plain Create enrollment call — the data consent created in Stage 0 does not change how you use it:

1. Register the device with Enrollment device options and Register enrollment device (FIDO2/WebAuthn).
2. Resolve the Pix key or QR code with Get Pix key or QR Code details, then open the payment consent with Create payment consent.
3. Execute the payment with Authorise payment, and track it with Get payment request.

Error handling

Every error response uses the same contract: message (array of strings), type, errorCode, traceId, and statusCode.

API reference

Use the Linked Journey (JSR) API group in the sidebar for full request and response schemas.