# SSM Input Api
SSM apps must authenticate using the OAuth 2.0 specification (opens new window)to use SSM’s API resources. This guide shows you how to authenticate an app using OAuth.
# The OAuth flow
SSM uses OAuth 2.0’s authorization code grant flow (opens new window) to issue access tokens on behalf of users. The following diagram illustrates the OAuth flow based on the actions of the merchant, your app, and SSM.
- The merchant makes a request to install the app.
- The app redirects to SSM to load the OAuth grant screen.
- SSM displays a prompt to the merchant to give authorization to the app, and prompts the merchant to log in if required.
- The merchant consents to the scopes and is redirected to the
redirect_uri
. - The app makes an access token request to SSM including the
client_id
,client_secret
, andcode
. - SSM returns the access token.
- The app uses the access token to make requests to the SSM API.
- SSM returns the requested data
# 1. Get API credentials
The first step is to retrieve an API key and API secret key. These API credentials identify your app during the authorization process. In order to get these please contact the support team.
# 2. Ask for permission
Before an app can access any store data, a merchant must grant permission to the app. Granting permission happens when a merchant clicks the link to install your app.
# How the installation flow works
After a merchant clicks the link to install your app, your app receives a GET
request on the app URL path that you specified for the support team. Requests to this URL path from a merchant who is logged into the SSM App Store include the hmac
query parameters.
You need to verify the authenticity of these requests using the provided HMAC. For more information, refer to Verification.
# Installation permissions prompt
SSM shows the following prompt to receive authorization from the merchant.
Show the installation permissions prompt To show the prompt, redirect the merchant to the following URL with the query parameters defined below:
https://platform.supersalesmanagerapp.com/#/portail/oauth/partners?client_id={api_key}&redirect_uri={redirect_uri}
Query parameter | Description |
---|---|
{api_key} | The API key for the app. |
{redirect_uri} | The URL to which a merchant is redirected after authorizing the app. The complete URL specified here must be added to your app as an allowed redirection URL. |
# 3. Confirm installation
When the merchant clicks the install button in the prompt, they’re redirected to your app's server. The authorization_code is passed in the confirmation redirect:
https://example.org/some/redirect/uri?code={authorization_code}&hmac=da9d83c171400a41f8db91a950508985}
# Security checks
Before you continue, make sure that your app performs the following security checks. If any of the checks fail, then your app must reject the request with an error, and must not continue.
- The
hmac
is valid and signed by SSM.
# 4. Get a permanent access token
If all security checks pass, then you can exchange the access code for a permanent access token by sending a request to the shop’s access_token endpoint:
POST https://api.supersalesmanagerapp.com/api/oauth/partners/token
In your request, you must provide in the request body:
Parameter | Description |
---|---|
client_id | The API key for the app, as defined in the Partner Dashboard. |
client_secret | The API secret key for the app. |
code | The authorization code provided in the redirect. |
The server responds with an access token:
{
"access_token": "f85632530bf277ec9ac6f649fc327f17"
}
The following values are returned:
Value | Description |
---|---|
access_token | An API access token that can be used to access the shop’s data as long as your app is installed. Your app should store the token somewhere to make authenticated requests for a shop’s data. |
# 5. Make authenticated requests
After your app has obtained an API access token, it can make authenticated requests to the SSM API. These requests a Bearer token like this: Bearer {access_token}
where {access_token}
is replaced with the permanent token.
# Verification
Every request or redirect from SSM to your app's server includes an hmac parameter that can be used to verify the authenticity of the request from SSM. For each request, you must remove the hmac entry from the query string and process it through an HMAC-SHA256 hash function.
The following is an example of a query string. However, request parameters provided by Shopify are subject to change. Your verification strategy shouldn't depend on the parameters in the following example:
"code=0907a61c0c8d55e99db179b68161bc00&hmac=700e2dadb827fcc8609e9d5ce208b2e9cdaab9df07390d2cbca10d7c328fc4bf"
# IDs array parameter
If your query string includes an ids
array parameter, then the query string is parsed so that ids[]=1&ids[]=2
gets converted to ids=["1", "2"]
before the signature is generated.
# Remove the HMAC
To remove the hmac
, you can transform the query string to a map, remove the hmac
key-value pair, and then lexicographically concatenate your map back to a query string. This leaves the remaining parameters from the example query string:
"code=0907a61c0c8d55e99db179b68161bc00"
# Process through the hash function
You can process the string through an HMAC-SHA256
hash function using the secret key. The message is authentic if the generated hexdigest is equal to the value of the hmac
parameter.
The following Ruby example shows how to process the string through a hash function:
digest = OpenSSL::Digest.new(’sha256’)
secret = "hush"
message = "code=0907a61c0c8d55e99db179b68161bc00&shop=some-shop.myshopify.com&state=0.6784241404160823×tamp=1337178173"
digest = OpenSSL::HMAC.hexdigest(digest, secret, message)
ActiveSupport::SecurityUtils.secure_compare(digest, "700e2dadb827fcc8609e9d5ce208b2e9cdaab9df07390d2cbca10d7c328fc4bf")
Orders →