Changelog

#2026-09

• A decryption key is now required. Install yours before registering a Connect client: the client registration refuses without one, and /oauth/authorize answers temporarily_unavailable with error_description naming the missing key. It takes a minute at /app/partner — generate a P-256 key pair, install the public half, answer the possession challenge. Your users are then never asked to invent a passphrase, and you hold the only key that can read their data. Keep it: if you lose it, that data cannot be recovered.

• response_type=code is required for obc_ clients (introduced 2026-08; documented in the reference since, but not recorded here until now). The re-entry our own consent page uses after onboarding omitted it, so a first-time user of an obc_ client finished the whole journey and landed on your callback with error=invalid_request. Fixed on our side; nothing to change in your integration.

• With your own recipient key, consent now comes before the bank step: the user approves, connects their bank, and the relay follows without a second approval. With the browser key relay the order is unchanged. Either way your callback sees exactly what it saw before.

• challenge=pin_code is worth sending in a redirect journey too — it keeps the login in one window instead of mailing a link that opens in a new tab.

• Size your state record for 45 minutes, not ten: a first-time user signs in, consents, picks a bank and passes its strong customer authentication before your callback runs. The published examples said ten, which refused real journeys.

• ui_locales and login_hint now survive the onboarding re-entry, so a forced flow language holds for every screen and the hint is applied on the way back as well as on the way in.

#2026-08

• Discovery at /.well-known/oauth-authorization-server (RFC 8414) with the open_banking_io extension.
• response_mode defaults to form_post (the spec default is query): the relay carries the user's key and never rides a query string. Configure your client library to request and accept form_post.
• /oauth/authorize errors after client validation are delivered by form_post to the redirect URI with error, error_description, iss and state; earlier errors answer 400 with a JSON body.
• /oauth/token accepts the standard form-encoded request with client_secret_basic or client_secret_post, answers RFC 6749 errors, and adds access_token, token_type, expires_in and scope to the response. The JSON request shape and the apiKey, apiBaseUrl, user fields keep working.
• Keys may be sent as Authorization: Bearer ebk_… as well as X-Api-Key.
• POST /oauth/revoke (RFC 7009) and GET /oauth/userinfo.
• The relay carries iss.
• A wrong client secret answers 401 { "error": "invalid_client" } (was an empty 401).
• The sync failure partner_app_inactive (503).
• Each partner runs on its own Enable Banking application; each user connecting through a partner lives in a tenant of their own.

#Other SDKs

The Node client is the reference for Connect helpers. Go, Python, .NET, Java, PHP, Ruby and Rust read data with the same key and decrypt the same envelopes; the flow itself is plain OAuth 2.0 with PKCE and any client library that supports form_post and client_secret_basic will do.