All our REST based APIs are secured by the OAuth 2.0 protocol using our Authorization Server. The Authorization Server supports the Client Credentials and Authorization Code Grant flows for
single page application, native device apps and server based applications.
OAuth 2.0 is a fairly simple protocol, and a developer can integrate OAuth 2.0 without too much effort.
On this site you will find documentation on how to use the OAuth 2.0 endpoints provided by the Authorization Server, to obtain access tokens to call a secured API.
To be able to obtain an access token for your app or service. You should first register your organisation and request an integrator account.
After registration you will receive a OAuth ClientId and Client Secret.
Visit the eWastra Portal and sign in or follow the register link to create a new account.
Make sure that you provide us with all the necessary information to validate,
your application for an account and to validate the organisation you work for.
Please use a correct e-mail address, phone number and VAT Identification number
for your organisation.
Before your application can access a eWastra API, it must obtain an access token that grants access to that API.
The eWastra Authorization Server support a number of ways to request an access token. Depending on your scenario, you can use the following OAuth 2.0 grants:
Implement this scenario if you need to author (create, issue and manage) consignment notes for your own organization or the organization of a customer.
To call the API, you will first need to obtain an access token for the organisation. This can be done using the OAuth 2.0 Client Credentials grant.
You will need additional connection credentials from the organization for which you want to author the consignment notes. Contact our support service at
support@pionira.be for the connection credentials for a certain organization.
Obtain the access token from the token endpoint of our Authorization Server located at https://portal.ewastra.com/oauth2/token (Production environment)
https://apps-test.xynaps.net/oauth2/token (Test environment)
For example, a request for an access token is sent using the client credentials grant type. All necessary parameters are sent form url encoded:
POST oauth2/token HTTP/1.1
Host: portal.ewastra.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=7979797YIYZYEZ&client_secret=66YD82D2DOZIADDAFDAOD
After successful validation of the client credentials, the server responds with the following response:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"164ajioAEJ6868yUpkk831385",
"token_type":"bearer",
"expires_in":3600
}
When you retrieve an access token, use it in the authorization header to call the API.
For example:
GET /api/v2/transportdocuments/12 HTTP/1.1
Host: portal.ewastra.com
Authorization: Bearer 164ajioAEJ6868yUpkk831385
After you have obtained an access token, you can use it an HTTP authorization header. We do not support sending access tokens in the query string, as these query string parameters can be logged in log files that are not completely secure.
The validity of an access token is determined by its lifetime and the scope requested during the token request.
For example:
GET /api/v2/transportdocuments/12 HTTP/1.1
Host: portal.ewastra.com
Authorization: Bearer 164ajioAEJ6868yUpkk831385
As mentioned in the above steps, access tokens have limited lifetimes. If your application
needs access to an eWastra API beyond the lifetime of an access token,
it can obtain a refresh token. A refresh token allows your application to obtain new access tokens.
Save access and refresh tokens in secure storage and continue to use them as long as they remain valid. Limits apply to the number of refresh tokens that are issued per client-user combination, and per user across all clients, and these limits are different. If your application requests enough refresh tokens to go over one of the limits, older refresh tokens stop working.