Authentication
This part of the documentation shows you how to authenticate with the sellytics DATA API.
The DATA API makes use of the OAuth2 client_credentials
flow with Bearer Tokens.
This grant-type was not made to be used in client-side applications since you shouldn't ever expose your client-secret to the public world.
So if you want to show some data in a client-side application create at least an upstream proxy with your own authentication or protection.
You can read more about the client_credentials
grant type here.
#
Get API Credentials (API Key)To get your own sellytics DATA API credentials login to the sellytics-suite with your sellytics account. Choose your space where for which you want to create API credentials and go to the DATA API module. Use the "Create new key"-Feature in the API Keys section to create new API credentials. You can optionally add a label to your credentials to know for what or which project you've created the key.
warning
API keys cannot be recovered - so store them carefully!
access_token
#
Get a Bearer To make API calls / requests to the sellytics DATA API you always have to send a Bearer (Auth) Token in every request header.
You can obtain the bearer token using client_credentials
OAuth2 grant type from our token-endpoint.
Property | Value |
---|---|
Token endpoint | https://auth.sellytics.com/realms/sellytics/protocol/openid-connect/token |
Scope | sellytics-data-api |
access_token
#
Using the Example request using curl to get the access_token
, using the client_credentials
grant type:
When the request was successful you should get a response json payload with your Bearer access_token
.
You can use this access_token
now to make authenticated requests against the sellytics DATA API.
refresh_token
in DATA API context#
We don't recommend using Since the sellytics DATA API is using client_credentials
OAuth2 grant which is designed for server-side clients and access where the client_id
and client_secret
aren't visible to the public world you don't need to use the refresh_token grant and feature.
The issuance of a refresh token with the client_credentials grant has no benefit. That is what the RFC6749 section 4.4.3 indicates but many authorization servers including ours do not respect.
So it is enough to just re-authenticate when the access_token
is expired with the client_credentials grant as described in the paragraph above.