PSD2 Context: PSD2 requires customers to have access to their account information via third party applications.
This call provides balance and other account information via delegated authentication using OAuth.

Authentication is required if the 'is_public' field in view (VIEW_ID) is not set to true.

Returns the list of accounts at BANK_ID that the user has access to.
For each account the API returns the account ID and the views available to the user..
Each account must have at least one private View.

The account is specified by ACCOUNT_ID. The information is moderated by the view specified by VIEW_ID.

Number

Owners

Type

Balance

Routing

PSD2 Context: PSD2 requires customers to have access to their account information via third party applications.
This call provides balance and other account information via delegated authentication using OAuth.

Get public accounts at all banks (Anonymous access).
Returns accounts that contain at least one public view (a view where is_public is true)
For each account the API returns the ID and the available views.

An OBP Consent allows the holder of the Consent to call one or more endpoints.

Consents must be created and authorisied using SCA (Strong Customer Authentication).

That is, Consents can be created by an authorised User via the OBP REST API but they must be confirmed via an out of band (OOB) mechanism such as a code sent to a mobile phone.

Each Consent has one of the following states: INITIATED, ACCEPTED, REJECTED, REVOKED.

This endpoint starts the process of creating a Consent.

The Consent is created in an INITIATED state.

A One Time Password (OTP) (AKA security challenge) is sent Out of Bounds (OOB) to the User via the transport defined in SCA_METHOD
SCA_METHOD is typically "SMS" or "EMAIL". "EMAIL" is used for testing purposes.

When the Consent is created, OBP (or a backend system) stores the challenge so it can be checked later against the value supplied by the User with the Answer Consent Challenge endpoint.

These message docs provide example messages sent by OBP to the (Kafka) message queue for processing by the Core Banking / Payment system Adapter - together with an example expected response and possible error codes.
Integrators can use these messages to build Adapters that provide core banking services to OBP.

Note: API Explorer provides a Message Docs page where these messages are displayed.

This endpoint provides example message docs in swagger format.
It is only relavent for REST Connectors.

This endpoint can be used by the developer building a REST Adapter that connects to the Core Banking System (CBS).
That is, the Adapter developer can use the Swagger surfaced here to build the REST APIs that the OBP REST connector will call to consume CBS services.

Get documentation about the RESTful resources on this server including example bodies for POST and PUT requests.

This is the native data format used to document OBP endpoints. Each endpoint has a Resource Doc (a Scala case class) defined in the source code.

This endpoint is used by OBP API Explorer to display and work with the API documentation.

Most (but not all) fields are also available in swagger format. (The Swagger endpoint is built from Resource Docs.)

API_VERSION is the version you want documentation about e.g. v3.0.0

You may filter this endpoint with tags parameter e.g. ?tags=Account,Bank

You may filter this endpoint with functions parameter e.g. ?functions=enableDisableConsumers,getConnectorMetrics

For possible function values, see implemented_by.function in the JSON returned by this endpoint or the OBP source code or the footer of the API Explorer which produces a comma separated list of functions that reflect the server or filtering by API Explorer based on tags etc.

operation_id is concatenation of "v", version and function and should be unique (used for DOM element IDs etc. maybe used to link to source code)

version references the version that the API call is defined in.

function is the (scala) partial function that implements this endpoint. It is unique per version of the API.

request_url is empty for the root call, else the path. It contains the standard prefix (e.g. /obp) and the implemented version (the version where this endpoint was defined) e.g. /obp/v1.2.0/resource

specified_url (recommended to use) is empty for the root call, else the path. It contains the standard prefix (e.g. /obp) and the version specified in the call e.g. /obp/v3.1.0/resource. In OBP, endpoints are first made available at the request_url, but the same resource (function call) is often made available under later versions (specified_url). To access the latest version of all endpoints use the latest version available on your OBP instance e.g. /obp/v3.1.0 - To get the original version use the request_url. We recommend to use the specified_url since non semantic improvements are more likely to be applied to later implementations of the call.

summary is a short description inline with the swagger terminology.

description may contain html markup (generated from markdown on the server).