All APIs follow the REST architectural style, meaning that all calls consist of an https call (GET, POST, PUT, DELETE) returning a JSON object.  

The APIs are divided in three categories regarding security:

• Public APIs, which do not reference or manipulate customer data, so anyone can access them.  They do not require customer authentication, since they provide public information. 

For example, the product PB API General Info contains APIs which return information about branch/ATM location. The API GET /POP/{PointTypeName}/list returns all points of presence (POPs) of the specified PointTypeName.  eg ATM.

The required parameters for this call are:

• X-IBM-Client-Id (required), with the value of the application ID we saved durring application registration.
• Accept header (optional), with value application/json
• PointTypeName (required), in path.  Possible values are Branch, ATM, APS, eBranch, All

• Informational APIs, that provide information about the customer, its products, or their transactions.  The informational APIs require customer authentication, since they involve customer private data. 

For example, the product PB API Accounts includes APIs which return account list/details/transactions.

To call its API GET /{accountId}/details, the parameters needed are:

• X-IBM-Client-Id (required), with the value of the application ID we saved durring application registration.
• Authorization header (required), with the value returned from the oauth2 procedure.  It has the form "Bearer token", where "token" is retured from oauth.
• Accept header (optional), with value application/json
• accountId (required), in path.  accountId, is a unique per account, per session. 

• Monetary APIs, which transfer funds in various ways. Monetary APIs require customer authentication, as well as second factor authentication, for increased security.

For example, the product PB API Transactions involves APIs for single/bulk transfer from a customer account to an IBAN, internal or external of the bank. 

To make a POST request for the API /TransferToIban, the necessary parameters are :

• X-IBM-Client-Id (required), with the value of the application ID we saved durring application registration.
• Authorization header (required), with the value returned from the oauth2 procedure.  It has the form "Bearer token", where "token" is retured from oauth.
• Accept header (optional), with value application/json
• transferToIban_Input (required), in body.  json object containing the needed information to complete the transfer. for example destination iban, amount and currency, etc

Notes

• All APIs, even the public ones, need the Client id (Application id), within the header variable x-ibm-client-id to allow you to execute them.
• There are APIs that return a list of items.  If those items are in subsequent calls needed as input, then these items have a unique Id that is used as that input. For example, accounts have an accountId, cards have a cardId, etc.  In order to get the transactions of an account, this accountId will be needed as input.  These Ids are unique per item and per session, thus you cannot store these Ids, and after each login, you need to request the API that returns their list again. This may seem counter-intuitive development-wise, but ptovides extra security for the transmitted data.
• Most monetary transactions need an extra user verification proccess, called second factor authentication, described at a later page.