Ready to build your apps? Get started by following a few simple steps.
A “how-to” guide to use our banking APIs
As a third party app provider, go through the following steps in order to use our APIs :
Navigate through our API products catalogue and leverage the wide range of opportunities given
Group API Products catalog
Create your account Sign up
- Try the APIs
Try the APIs using the built-in testing functionality to get an understanding of how it works.
- Create and register your Sandbox Application
Register an Application in your Account Profile to get your Client ID and Secret. Subscribe to one or more of our sandbox products that fit your needs in order to receive your subscription keys.
Use the sandbox environment to get familiar with the Alpha Bank products, explore their features and test your applications with the provided sample data. The sandbox features the same functionality as the production APIs, so you can be sure that your applications will integrate smoothly with the production APIs.
- Create and register your Production Application
When you’re finished testing, submit your application for the production data, upload any certificate required (e.g. eIDAS for PSD2 API Products), subscribe to our Production APIs, get authorized and go live!
Download Open API Specification Documentation
Download Open API Specification (YAML)
The APIs are accessible at the following URLs. Refer to the API documentation above for details on the endpoints.
|Production Base URLs|
|Alpha Bank Greece||https://gw.api.alphabank.eu/gr/api/|
|Alpha Bank Cyprus||https://gw.api.alphabank.eu/cy/api/|
|Alpha Bank Romania||https://gw.api.alphabank.eu/ro/api/|
Authentication and Authorisation
The use of the offered APIs is protected by an authentication/authorisation server (Auth server). The server is compliant with the OAuth2 standard and accessible at the following endpoints.
|Production environment Auth server endpoints|
|Alpha Bank Greece|
|Sandbox environment Auth server endpoints|
The use of specific grant types and/or scopes is required at specific cases during the flow of using the offered functionality.
The basic concept behind the main usage scenarios is based on a two-phase execution. The first phase is related to the creation of an intent object by the client application. The second phase is about the authorisation of this intent object by the end user and the use of the required API operations.
All inbound HTTP requests to the Alpha Bank's API endpoints must be digitally signed using an eIDAS certificate with QSealC profile (as defined in ETSI TS 119 495) for all cases that the request carries a payload.
When a client application is registered to the portal, the developer is responsible to submit at least one certificate, which will be used to sign the client application payloads. The signature must be attached to every client application request. The API will validate this signature against the uploaded application certificate. In case of a missing/invalid signature header, or invalid (expired or revoked) certificate, the request is ignored and the client application that made the calls receives an Http 400 (Bad request) error.
A similar to the aforementioned process applies to the responses sent from the bank’s servers. All the returned payloads are signed using Alpha Bank’s certificates and the client applications have to validate the signature header. Depending on the bank, bellow is the list of active Alpha Bank’s certificates.
JSON Web Signature
JSON Web Signature (JWS) represents content secured with digital signatures using JSON-based data structures. Based on the RFC 7515 – Appendix F, the signing is performed using a JWS with detached content, and the HTTP body contains the un-encoded payload as defined in RFC 7797. The JWS must be signed using the algorithm RS256 that supports asymmetric keys. The TPP’s private key is used to sign the requests to the ASPSP, and the ASPSP’s private key is used to sign the responses to the TPPs.
Process for Signing Payloads
- The signer must use the private key of the certificate. At the time of the singing, the following requirements must be met.
- The certificate is valid
- The certificate has already been provided to the Alpha Bank Group API Portal, under the client application that will make the request.
- As described in the following table, the JOSE header must contain the subsequent fields.
Claim Description alg The algorithm used for signing. It must be set to RS256. typ This is an optional claim. If it is specified, it must be set to the value "JOSE" cty This is an optional claim. If it is specified, it must be set to the value "application/json". kid This must match the thumbprint value of the certificate. Possible spaces within the value must be removed. iat This must be a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in GMT until the date/time. b64 This must be false. It is used to indicate that the payload is not base 64 encoded.
- The signature must be computed as defined in RFC 7515 – Appendix F.
- The HTTP header called x-jws-signature must be included, along with the computed during the previous step, value.
Example of JWS signature
x-jws-signature : eyJhbGciOiJSUzI1NiIsInR5cCI6IkpPU0UiLCJjdHkiOiJhcHBsaWNhdGlvbi9qc29uIiwia2lkIjoiMjQ1MDAxODlmYzY0ZjE5ZGJjM2NhODI2ZjdmMTE0MGNl
Process for verifying signatures
- The verifier must extract the claims from the HTPP header named x-jws-signature.
- The JOSE header must be validated according to the values described in the previous table
- The verifier must retrieve the certificate with the specified kid value. The kid value is equivalent to the certificate thumbprint.
- The verifier must ensure that the retrieved certificate is valid.
- The verifier must verify the signature as defined in RFC 7515, Appendix F.
Sample of decoded Jose header
Creation of an intent object
The creation of the intent object is performed by the client application alone without an intervention by the end user. This phase includes two steps. The first step is the acquisition of an access token from the authorization server token endpoint using client credentials. The credentials are provided to the requests using HTTP basic authentication.
|Scope||account-info-setup or transfer-setup depending on the intended processes|
Supplying this access token to the appropriate intent object generation API operation (using the Authorisation header), the client application asks for the generation of an intent object (account information or payment intent object). The API operation responds with an intent identifier.
Authorisation of the intent object
This second phase is about authorising the intent object created during the first phase described above. This authorisation is performed as an authorisation code three-legged OAuth2 flow.
The end-user is redirected by the client application to the authorisation endpoint of the Auth server and the UI is presented to the end-user using the default operating system web browser. The parameters to the authorisation request are:
|client_id||The client_id is assigned by Alpha Bank as an identifier to the client application|
|redirect_uri||The location (URL) the end user will be redirected after completion of the authorisation process. This URL must be known and associated with the client application.|
|request||The identifier of the intent object created at the end of the previous phase (see description above)|
A successful request to the authorisation endpoint with the parameters above results in the rendering of an authentication interface. The end user is asked for his username, password in the Alpha Bank e-Banking. The authentication is performed at the Alpha Bank e-Banking backend systems.
After authenticated (logging-in) the end-user is presented with a consent screen, which reflects a representation of the intent object created during the first phase. In case of account-information request intent object the end user is asked for giving authorisation to the client application to make calls to the account information and transactions only API operations on behalf of the end user for a given duration.
In the case of a Payment intent, the end user is presented with the details of the intended payment, such as creditor information, amount, expenses, etc. The user is asked for selecting his account to be used for the payment (if not preselected) and a second-factor authentication if necessary.
Upon acknowledging the authorisation of the client application, the authorisation server responds with and authorisation code. This authorisation code is subsequently used by the client application in order to acquire an intent object bound access token. The access token is acquired with a request to the token endpoint using the following parameters.
|client_id||The client_id is assigned by Alpha Bank as an identifier to the client application|
|client_secret||The «password» of the client application|
|redirect_uri||The location (URL) the end user will be redirected after completion of the authorisation process. This URL must be known and associated with the client application. Must be the same used during auth code request.|
The result of the call to the token endpoint is a new access-token which is bound to the specific intent object. This access token is then used (as value to the Authorisation header) by the client application with any request related to the execution of the intent object.
Use the sandbox environment to get familiar with the Alpha Bank products, explore their features and test your applications with the provided sample data. For the scope of the sandbox we have created a set of non-real accounts that you can use to develop your applications. To get access to these sample accounts, use one of the following test users when you get redirected to the Alpha bank login screen.
Remember to review the documentation of each API and test them before you start using them.
The sandbox features the same functionality as the production APIs, so you can be sure that your applications will integrate smoothly with the production APIs.