Get Started Krungsri API portal -Krungsri Developers

How to...

:)Sign up

To start try our APIs, you need to sign up for an account.

Step to do:

Go to Sign up page.
Fill in Sign Up form and Submit, then we'll send you an email with a link to activate your account.
Click Link to Activate account, then Log In.
In My Apps page you can see Sandbox Application that we created 1 for your account.

:)Play in our Sandbox

If you are passing by or non-technical guy you can easily obtain how our APIs work by craftly create GUI on our API explorer.

Step to do:

Go to Sandbox Explorer Page
Click button Get Token. It will automatically call authentication API and get Bearer Token for you.
Select API to play.
Input parameter.
Click Submit to call API.

Play in our Sandbox | Get Started Krungsri API portal - Krungsri Developers

:)Call our APIs

If you has experience and want to feel real life API call so please use HTTP Client that you like (ex. Postman, SOAPUI, HTTPBOT, etc) to play with sandbox.

To be more precise please embrace our nicely create authentication method below.

For Server-to-Server we use OAuth2 Client Credentials to secures these APIs. All APIs specification provided on the Developer Portal are swagger 2.0 based. The swagger file describes all information required to make a valid request and all the needed authentication in the securityDefinitions section. The swagger file can be downloaded from the Developer Portal.

Call our APIs to play with sandbox | Get Started Krungsri API portal - Krungsri Developers

a. Request Access Token: OAuth2 Client Credentials Grant

The partner application needs to provide its own credentials to connect to OAuth2 API with Basic Authentication (Client ID and Client Secret) to retrieve an access token.

A typical request access token would look like this, where the scope is not specified:

                            
    curl -X POST -d "grant_type=client_credentials" -H "Authorization: Basic bDdjZW..."
    https://sandbox.api.krungsri.com/auth/oauth/v2/token

With scopes provided:

                            
    curl -X POST -d "scope=transfer:onus+inquiry:offus&grant_type=client_credentials" -H "Authorization: Basic bDdjZW..."
    http://sandbox.api.krungsri.com/auth/oauth/v2/token

What is Client ID and Client Secret?
Client ID(API-Key)
The public identifier of your application. It’s used in every call so we can tell who’s requesting information.
Client Secret
This is the private identifier of your application. It allows us to verify your identity in the authentication step of our APIs.

b. Response Access Token

Various responses are possible, where only HTTP status 200 means a successful authentication:

HTTP POST method was not used

                            
    HTTP/1.1 405 Method Not Allowed
    {
    "error":"invalid_method",
    "error_description":"GET not permitted"
    }

The pair Client ID, Client Secret is not valid. Please recheck these values in the Developer Portal and ensure the application is active

                            
    HTTP/1.1 401 Unauthorized
    {
    "error":"invalid_client",
    "error_description":"The given client credentials were not valid"
    }

The “Required Grant Type” is empty, and client_credentials grant type should be part of it

                            
    HTTP/1.1 401 Unauthorized
    {
    "error":"unauthorized_grant_type",
    "error_description":"No configuration allow_grant_type for this client has been requested"
    }

The client_credentials grant type is not part of the “Required Grant Type” list

                            
     HTTP/1.1 401 Unauthorized
     {
     "error":"unauthorized_grant_type",
     "error_description":"The specified value for grant_type is not allowed for the client"
     }

Invalid grant type value, please recheck it is set to client_credentials

                            
    HTTP/1.1 400 Bad Request
    {
    "error":"unsupported_grant_type",
    "error_description":"The given grant_type is not supported"
    }

The required scope is not part of the allowed scope in the Developer Portal

                            
    HTTP/1.1 400 Bad Request
    {
    "error":"invalid_scope",
    "error_description":"No registered scope value for this client has been requested"
    }

Successful authentication with the requested scope(s)

                            
    HTTP/1.1 200 OK
    {
    "access_token":"11da2e69-1774-4e9a-b0ab-103b4669110d",
    "token_type":"Bearer",
    "expires_in":3600,
    "scope":"transfer:onus inquiry:offus"
    }

Successful authentication with the default scope

                            
    HTTP/1.1 200 OK
    {
    "access_token":"008b3a58-065e-422c-b97f-3efe75017a64",
    "token_type":"Bearer",
    "expires_in":3600,
    "scope":"oob"
    }

c. Call Any API with Access token

The access token can then be used to make an API call for example:

A typical request access token would look like this, where the scope is not specified:

                            
    curl -X POST -H "X-Client-Transaction-ID: 4b3214dd-4db0-496a-baf1-b269f33fde1f"
    -H "API-Key: l7cee87..."
    -H "Content-Type: application/json; charset=UTF-8"
    -H "Authorization: Bearer 11da2e69-1774-4e9a-b0ab-103b4669110d"
    --data [JSON_BODY_DATA] https://sandbox.api.krungsri.com/[END_POINT]

The following request header headers are commonly used. Note that a header field is case insensitive according to RFC 7230 (section 3.2).

Authorization

Description

Bearer type authentication (OAuth Token) are supported. The swagger file describes the API requirements. More information about authentication and authorization can be found here.

Examples

Bearer mytoken123

Content-Type

Description

When there is a request body, indicated the content type according to RFC 7231 (section 3.1.1.5) Most APIs today only support content type: application/json, where UTF-8 is mandated.

Examples 1

application/json; charset=utf-8

X-Client-Transaction-ID

Description

UUID v4 (based on RFC4122), generated by the client. It is used to identify uniquely the transaction for audit or investigation purpose. It is the client responsibility to make it unique. The gateway does not validate its uniqueness. See below for sample code provided to help our developers generate UUID v4.

Examples

38359a61-8128-4aba-9e7f-2f556610fa76

Digest

Description

Request body digest (hash) as per RFC 3230. Client must compute SHA256 hash of request body and provide to this header

** Require for financial API

Examples

SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=

Signature

Description

This is HTTP Signature as per IETF Signing HTTP Messages (draft-cavage-http-signatures-12) - > https://tools.ietf.org/html/draft-cavage-http-signatures-12

Client must provide this signature to ensure message integrity. Below list is of minimum HTTP header that required to include in signature generation / validation

(request-target)

(created)

digest

X-Client-Transaction-ID

Client can use more header but this is minimum requirement.

** Require for financial API

Examples

keyId="Test",algorithm="rsa-sha256", created=1402170695, expires=1402170699, headers="(request-target) (created) (expires) host date content-type digest content-length", signature="vSdrb+dS3EceC9bcwHSo4MlyKS59iFIrhgYkz8+oVLEEzmYZZvRs 8rgOp+63LEM3v+MFHB32NfpB2bEKBIvB1q52LaEUHFv120V01IL+TAD48XaERZF ukWgHoBTLMhYS2Gb51gWxpeIq8knRmPnYePbF5MOkR0Zkly4zKH7s1dE="

Header Field	Description	Examples
Authorization	Bearer type authentication (OAuth Token) are supported. The swagger file describes the API requirements. More information about authentication and authorization can be found here.	Ex1: Bearer mytoken123
API-Key	Client ID from Partner Application	l7ee87…
Content-Type	When there is a request body, indicated the content type according to RFC 7231 (section 3.1.1.5) Most APIs today only support content type: application/json, where UTF-8 is mandated.	Ex1: application/json; charset=utf-8 Ex2 : application/xml ; charset=TIS-620
X-Client-Transaction-Datetime	Date and Time on the client side, following format ISO8601.	1997-07-16T19:20:30.45+07:00
X-Client-Transaction-ID	UUID v4 (based on RFC4122), generated by the client. It is used to identify uniquely the transaction for audit or investigation purpose. It is the client responsibility to make it unique. The gateway does not validate its uniqueness. See below for sample code provided to help our developers generate UUID v4.	38359a61-8128-4aba-9e7f-2f556610fa76
X-Signature	Signature of request body using the “Signature Key” as provided in the Application Information, inside the Developer Portal. Algorithm used: HMAC SHA-256 More information and sample code are provided in the next section here	hKUKvKvcYQu7gmqrYOOq6F1D2Lt+Js/mG4D3vj/fxmk=

d. Response from API

The following response headers are commonly used.

Content-Type

Description

Indicates the response content type according to RFC 7231 (section 3.1.1.5) Most APIs today only support content type: application/json, where UTF-8 is mandated.

Examples 1

application/json; charset=utf-8

Examples 2

application/xml ; charset=TIS-620

X-Client-Transaction-ID

Description

UUID (based on RFC4122) provided in the request header by the Client to identify uniquely the transaction.

Examples

38359a61-8128-4aba-9e7f-2f556610fa76

X-Server-Transaction-ID

Description

UUID generated by the Krungsri API gateway to uniquely identify the transaction

Examples

ed572fae-80a5-4763-a0c7-1cc60a3ba2b5

X-Server-DateTime

Description

Date and Time on the server side, following ISO8601 format

Examples

1997-07-16T19:20:30.45+07:00

What is Message Digest and Signature?

Following API international best practices, message digest and signature brings additional security on top of the standard network
encryption for highly sensitive API calls. In the (unlikely) case the network layer security is compromised, this additional security
layer adds complexity of a hacker to alter the message request and its associated signature.

Digest

Digest is RFC 3230 standard, designed to validate message integrity.

Client must calculate hash value of request body and encode in base64 encoding with SHA-256 of then put in header name “Digest”

Sample HTTP Request

       POST /foo?param=value&pet=dog HTTP/1.1
       Host: krungsri.com
       Date: Sun, 05 Jan 2014 21:31:40 GMT
       Content-Type: application/json
       Content-Length: 18
    
       {"hello": "world"}

This is because Base64 encoding of SHA-256 of {"hello": "world"} is X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=

You can set that digest header is
Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=

Sample HTTP Request with Digest

       POST /foo?param=value&pet=dog HTTP/1.1
       Host: krungsri.com
       Date: Sun, 05 Jan 2014 21:31:40 GMT
       Content-Type: application/json
       Content-Length: 18
       Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
    
    
       {"hello": "world"}

List of Signature Field

Field name	Mandatory/Optional	Description	Sample Value
keyId	M	This value will indicate which key (and algorithm) to be use.	client-secret
algorithm	O	The algorithm to be use, as per latest specification we will support only 1 algorithm which is hs2019	hs2019
created	M	Unix timestamp of create date/time of this header	1402170695
expires	O	Unix timestamp of expire date of this request	1402170995
headers	M	List of header to be use in hash calculation , It provide in space separated value. All header provided in here must be in lower case Signature specification provide 3 special header name to be use in hash calculation (request-target) (created) (expires) Please refer to next table for description of this 3 special header name. Sample value `date (request-target) digest` This mean that we will compute hash from 3 header in following order date (request-target) digest	date (request-target) digest
signature	M	The parameter is a base 64 encoded Headers signature. The string input for digital signature calculation will explain in next section due to its complexity	WDNZzm22RFQs1uZUXmgVDgjDz379GzBbG939DJNP+8A=

Headers signature

Keyed-Hashing for Message Authentication Code (HMAC) using SHA-256 is used to create a hashed signatures with "Signature Key" and "Header combining String". The symmetric key is the "Signature Key" registered in the Developer Portal, as part of the Application detailed information. "Header combining String" will be combining all header and value of that header into single string in following format

Result string = "${headerLine1}\n${headerLine2}\n${headerLine3}......" where \n is newline charactor ${headerLine1} is header line 1 ${headerLine2} is header line 2 ${headerLine3} is header line 3 ......

   Headers line generation
  header line = ${headerName}: ${trimmedHeaderValue} where ${headerName} is header name ${trimmedHeaderValue} is trimmed(removing leading and trailing whitespace) header value   Each header line will be concatenate by \n (new line).

  The list of header and order to be concatenate is provided in signature’s header field
The digital signature will calculate using bellow pseudo code
Headers Signature = doHmacSha256Base64 (UTF8-byte-array
  (“Header1:Value1\nHeader2:Value2\n…\nHeadern:Valuen”), “Signature Key” )

Example digital signature
Algorithm is HMAC with signature key = don't tell

Headers Signature = doHmacSha256Base64 (UTF8-byte-array(digest: SHA- 256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=\ndate: Tue, 07 Jun 2014 20:51:35 GMT\n(request-target): post /foo/Bar"), "don't tell")
This will result in following headers signature
eMhtXlHAsQe6JQ+vcRgQ1OuttDPYRumXcfJRo+fY7+Y=

Sample HTTP Request with Digest and Signature

      POST /foo/Bar HTTP/1.1
      Host: example.com
      Date: Tue, 07 Jun 2014 20:51:35 GMT
      Content-Type: application/json
      Content-Length: 18 
      Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
      Signature: keyId="client-secret",algorithm="hs2019",created=1402170695,expires=1402170995,headers="digest date (request-target)",signature="eMhtXlHAsQe6JQ+vcRgQ1OuttDPYRumXcfJRo+fY7+Y="
           
      {"hello": "world"}

:)How to Become Partner

We are ready to help you reach your goals as a financial technology partnership to keep your business moving faster. In order to integrate with our production APIs, submit your idea through Contact Us menu. Then our sales will check out your business needs to determine if we will be a good fit, you'll agreed with Krungsri's Terms and Conditions then sign the MOU.

Our technical team will support on the integration.
API Testing will be performed and validated base on your use cases.
Once we are good on the testing then integrate to production APIs
Go live

:)Get Started Krungsri API portal

How to...

:)Sign up

:)Play in our Sandbox

:)Call our APIs

a. Request Access Token: OAuth2 Client Credentials Grant

b. Response Access Token

c. Call Any API with Access token

Description

Examples

Description

Examples 1

Description

Examples

Description

Examples

Description

Examples

d. Response from API

Description

Examples 1

Examples 2

Description

Examples

Description

Examples

Description

Examples

What is Message Digest and Signature?

Digest

Sample HTTP Request

Sample HTTP Request with Digest

List of Signature Field

Headers signature

Sample HTTP Request with Digest and Signature

:)How to Become Partner