Introduction to OAuth 2.0


userThe individual with access to a ChannelAdvisor account
scopeArea in which a developer is requesting access such as orders or inventory.readonly.
application IDThe developer’s application ID.  A developer should generate a unique application ID for each application they intend to develop (web, phone, desktop, backend service, etc.)
shared secretA secret shared between the developer and ChannelAdvisor.  Each application ID is generated along with a shared secret.  This secret should be kept private and never compiled into a client side desktop, phone, or javascript applications.  Only a web server or backend service should transmit the shared secret.  Certain authorization flows may require a developer to send the shared secret alongside an authorization request in order to prove their identity.
redirect uriA URL in which a developers application is redirected to once a user has granted access to the application.
response typeThe type of request being made to the authorization endpoint.  The value may either be  code  if an authorization code is being requested (Authorization Code flow) or  token if an access token is being requested (Implicit flow).
codeAn authorization code that is eligible to be exchanged for an access token.  Authorization codes are valid for 5 minutes and may only be exchanged once.
grant typeThe type of grant used obtain an access token and/or a refresh token.  This value may be  authorization_coderefresh_token , or  soap .
refresh tokenA refresh token is obtained through the Authorization Code flow.  This token expires after 3 months of non-use, and may be used multiple times to obtain a new access token.  A refresh token becomes invalid when the user revokes access to the application.
access tokenThe access token is the end goal for all authorization flows.  An access token is passed along with every request to ChannelAdvisor.  This token expires after 1 hour at which time the developer may use the refresh token or one of the alternate grant types to obtain a new access token.  For security reasons it is recommended that access token are passed in the HTTP Authorization Header of the request in the form of a Bearer token.  However, we also allow the access token to be passed through the query string.


Available Authorization Scopes


Combine scopes by separating them with a space (e.g. "orders inventory")