Back to CREATIS's Developer Portal Homepage

Open Banking API


PSD2 API Developer Portal Open Banking API

The Open Banking API offered by CREATIS is documented in detail in an OpenAPI ("Swagger") Specification file: View the OpenAPI Specification

This Open Banking API implementation is based on the documents produced by STET

In order to successfully send API requests, callers must respect a number of requirements:

  • They must be registered by CREATIS;
  • They must make the call with mutual TLS, with the appropriate Website Authentication Certificate;
  • They must have an access token that matches the target endpoint;
  • They must send a set of HTTP headers that allow the bank to check the request's validity;
  • They must sign the request with an appropriate Sealing Certificate;

The following sections will discuss the last two requirements, the other requirements have been described on the pages for Registration and OAuth 2 Endpoints.

Necessary and Signed Request Headers

The following headers are necessary, and must be signed:

  • Host: The standard HTTP header defined in RFC 7230;
  • Date: The standard HTTP header defined in RFC 7231, it needs to be set to a value that is not too far from the current date/time - otherwise an error will be returned;
  • X-Request-Id: This header, defined by STET, contains a correlation ID set by the TPP to uniquely identify each request made to the ASPSP API, with an ID that can be understood by both;

These headers must be present, and should not be signed:

  • Authorization: The HTTP header defined in RFC 7235, with the Bearer HTTP Authorization Scheme defined in RFC 6750, holds the OAuth 2 token previously obtained by the caller;

These headers must be present, and do not need to be signed:

  • Accept: The standard HTTP header defined in RFC 7231;
  • User-Agent: The standard HTTP header defined in RFC 7231;

If the request contains a body, the following additional headers are necessary, and must be signed:

  • Content-Type: The standard HTTP header defined in RFC 7231;
  • Digest: The HTTP header for instance digests, defined in RFC 3230. It should be noted that the only supported Digest Method is SHA-256, defined in RFC 5843;

The PSU-* family of headers, that allow the TPP to forward PSU device, location and usage information to the ASPSP, are facultative, but must be signed if present. The following headers are defined:

  • PSU-IP-Address: The IP Address on which the PSU is connected to the TPP;
  • PSU-IP-Port: The TCP Port of the PSU Terminal on which he is connected to the TPP;
  • PSU-Date: The timestamp of the relevant PSU action;
  • PSU-HTTP-Method: HTTP Method for the most relevant PSU's HTTP request to the TPP;
  • PSU-Accept: Accept HTTP header value for the most relevant PSU's HTTP request to the TPP;
  • PSU-Accept-Charset: Accept-Charset HTTP header value for the most relevant PSU's HTTP request to the TPP;
  • PSU-Accept-Encoding: Accept-Encoding HTTP header value for the most relevant PSU's HTTP request to the TPP;
  • PSU-Accept-Language: Accept-Language HTTP header value for the most relevant PSU's HTTP request to the TPP;
  • PSU-Referer: Referer HTTP header value for the most relevant PSU's HTTP request to the TPP;
  • PSU-User-Agent: User-Agent HTTP header value for the most relevant PSU's HTTP request to the TPP;
  • PSU-GEO-Location: The PSU location as returned by their mobile terminal;
  • PSU-Device-ID: The PSU Device ID - usually only available on a mobile terminal;

Signature process

The signature process uses the Cavage HTTP Signatures Draft, with the following specificities:

  • The HTTP Signature data must be in a Signature header;
  • In addition to the headers mentioned above, (request-target) (which summarizes the HTTP Status Line), must be signed;
  • The keyId must be set to a URL of a registered Sealing Certificate, sent to CREATIS when the OAuth 2 client was registered;
  • As the Sealing Certificates are RSA, only the rsa-sha256 algorithm is supported;