Getting started

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 :

  1. Explore 
    Navigate through our API products catalogue and leverage the wide range of opportunities given 
    Group API Products catalog
  2. Sign-up 
    Create your account Sign up
  3. Try the APIs 
    Try the APIs using the built-in testing functionality to get an understanding of how it works.
  4. 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.
  5. Test 
    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.
  6. 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)

API endpoints

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/

 

Sandbox Environment
Base URL https://gw.api.alphabank.eu/api/sandbox

 

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  
Token endpoint: https://secure.alpha.gr/auth/token
Authorisation endpoint: https://secure.alpha.gr/auth/authorize

 

Sandbox environment Auth server endpoints
Token endpoint: https://gw.api.alphabank.eu/sandbox/auth/token
Authorisation endpoint: https://gw.api.alphabank.eu/sandbox/auth/authorize

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.

Message Signing

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.

Alpha Bank Group (Sandbox) Download
Alpha Bank Greece (Production)
Download

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

  1. The signer must use the private key of the certificate. At the time of the singing, the following requirements must be met.
    1. The certificate is valid
    2. The certificate has already been provided to the Alpha Bank Group API Portal, under the client application that will make the request.
  2. 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.
  3. The signature must be computed as defined in RFC 7515 – Appendix F.
  4. The HTTP header called x-jws-signature must be included, along with the computed during the previous step, value.
Note

The JSON Web Signature (JWS) is optional for Sandbox.

 

Example of JWS signature

x-jws-signature : eyJhbGciOiJSUzI1NiIsInR5cCI6IkpPU0UiLCJjdHkiOiJhcHBsaWNhdGlvbi9qc29uIiwia2lkIjoiMjQ1MDAxODlmYzY0ZjE5ZGJjM2NhODI2ZjdmMTE0MGNl
YjFiZmM3NSIsImI2NCI6ZmFsc2V9.ewoJIlJpc2siOiB7fSwKCSJQcm9kdWN0SWRlbnRpZmllcnMiOiBbXQp9.sGmr_xU8tF2Tdo-O3yT5HpGmRfe2JeoZV
4qax-5_Bqcv_rFMQ4Qao3FZpdCMJZUvg-NL50TMCcBedup2WnsyjjofPFn2NzOapr10mV86Dj_pUyydQBkHEONeHO6Zsaf1CVEB4adEx5G46JlQXeb8p_70ZVH5TZXIkjVlz-JgQP0ATdKcREFOS_cO8P4l6WhY6SREL6iTye1Qn96rM4fyJtKKBNGlZ-hdo96EfYUcDa-Zd7A2InMe8B1k2ac5ZlM28wXWS4GsVG3Wukt01NnHayPIk_7ngsFYbtEneQQZkvsVdf949LYC2MzC5W8poTh7X2p7BUSIdwokkKzdoX72Bw

Process for verifying signatures

  1. The verifier must extract the claims from the HTPP header named x-jws-signature.
  2. The JOSE header must be validated according to the values described in the previous table
  3. The verifier must retrieve the certificate with the specified kid value. The kid value is equivalent to the certificate thumbprint.
  4. The verifier must ensure that the retrieved certificate is valid.
  5. The verifier must verify the signature as defined in RFC 7515, Appendix F.

Sample of decoded Jose header

{
   "alg": "RS256",
   "typ": "JOSE",
   "cty": "application/json",
   "kid": "24500189fc64f19dbc3ca826f7f1140ceb1bfc75",
   "b64": false
}

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.

grant_type client_credentials
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
response_type Code
scope account-info
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
grant_type authorization_code
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.

Sandbox

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.

Username Password
gpapadopoulos GPapadopoulos01
6ae
AEtaireia02
pgeorgiou PGeorgiou03
giwannou GIwannou04
aathanasiou AAthanasiou05
mmariou MMAriou06
aanastasiou AAnastasiou07
eeuaggelou EEuaggelou08
sstaurou SStaurou09
anastasis AAnastasiou10
kkwnstantinou KKwnstantinou11
ddimitriou DDimitriou12
mmatthaiou
MMatthaiou13

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.