Authentication Options

This article is outdated. Please click here to see the newer version.

APIMATIC supports various types of authentication. Please make sure that you select the correct type of authentication when describing your API i.e., the authentication type in the API description must match with the authentication type of the API. The generated code autmatically appends any authentication information with the subsequent API requests. Please find further information about the respective authentication types as follows.

No Authentication

Select this option if your API does not require any authentication. For skipping authentication only on a few of the enpoints, use the Skip Authentication option on the respective Endpoint description page.

Example:
GET /v1/Inventory HTTP/1.1
accept: application/json
user-agent: apimatic/1.0                
Host: acme.com
Connection: Keep-Alive

Basic Authentication

Basic authentication requires a username and a password to access the protected resources. When this option is used, two respective fields are generated in the constants file (see the contents of the generated code). When set, the values of these variables are used to sign the subsequent API requests. Note: It is highly recommended that SSL is used to perform the underlying HTTP requests. Ensure that the base url in the API Settings refers to a secure https url.

Example:
GET /v1/Inventory HTTP/1.1
accept: application/json
user-agent: apimatic/1.0
Authorization: Basic PFRPRE86IFJlcGxhY2U+OjxUT0RPOiBSZXBsYWNlPg==
Host: acme.com
Connection: Keep-Alive

OAuth 1.0

OAuth 1.0 provides authentication using cryptography hash computing method. The application developer (API Consumer) must acquire an access token by following a specific OAuth flow. When OAuth 1.0 authentication type is selected, two corresponsing variables are generated in the constants file that must be set the values of client secret and the acquired access token. Using the values of said variables, out going API requests are automatically signed with the computed hash. Note: Currently APIMATIC does not support token refresh mechanism and must be handled by the API consumer. Once the access token is refreshed, it can be used to update the previously set access token value.

Example:
GET /v1/Inventory HTTP/1.1
accept: application/json
oauth_consumer_key: 5e8591e4bb604356b0b7142b2bf0ce14
oauth_nonce: 353514065
oauth_timestamp: 1399245123
oauth_signature_method: HMAC-SHA1
oauth_version: 1.0
oauth_token: 607282b31a7544818d210eaff6533a84
oauth_signature: ZYvBXrXaoFBX1ip9wYR3VhZl2H4%3D
Authorization: OAuth oauth_consumer_key="5e8591e4bb604356b0b7142b2bf0ce14",oauth_nonce="353514065",oauth_timestamp="1399245123",oauth_signature_method="HMAC-SHA1",oauth_version="1.0",oauth_token="607282b31a7544818d210eaff6533a84",oauth_signature="ZYvBXrXaoFBX1ip9wYR3VhZl2H4%3D"
user-agent: apimatic/1.0
Host: acme.com
Connection: Keep-Alive

OAuth 2.0

OAuth 2.0 depends on the encryption of SSL layer to simplify the authorization, therefore it can only be used when the base url refers to a secure https url. Similar to OAuth 1.0, the application developer (API Consumer) must acquire an access token by following a specific OAuth flow. When OAuth 2.0 authentication type is selected, a corresponsing variable is generated in the constants file for the acquired access token. Using this value, out going API requests are automatically appended with the required authorization information. Note: Currently APIMATIC does not support token refresh mechanism and must be handled by the API consumer. Once the access token is refreshed, it can be used to update the previously set access token value.

Example:
GET /v1/Inventory HTTP/1.1
accept: application/json
Authorization: Bearer f80ff5694a454585bab0001a68ec5e9f
user-agent: apimatic/1.0
Host: acme.com
Connection: Keep-Alive

Custom Query

Some APIs require a custom query parameter to passed along with an API request for the purpose of authorization. This type of authentication requires definition of one or more parameters that are to be submitted along with the API requests. The corresponding variables generated in the constants file should either statically or programmatically from the application code. Note: the values of the said parameters will be transmitted as query parameters with all API requests, except where the endpoint description uses the skip authentication option.

Example:
GET http://acme.com/v1/Inventory?cauth=4c4112e4a1ef4e0f9396dbc80a160fc8 HTTP/1.1
accept: application/json
user-agent: apimatic/1.0
Host: acme.com
Connection: Keep-Alive

Custom Header

This type of authentication is similar to the custom query authentication method, except that the respective parameters are sent as header values rather than as query parametera. The values of the corresponding variables generated in the constants file will be transmitted as header values with all API requests, except where endpoint description uses skip authentication option.

Example:
GET http://acme.com/v1/Inventory HTTP/1.1
accept: application/json
cauth: 4c4112e4a1ef4e0f9396dbc80a160fc8
user-agent: apimatic/1.0
Host: acme.com
Connection: Keep-Alive
Have more questions? Submit a request

Comments