createAccessToken
Obtain an Access Token Allows a client to use its credentials to obtain an access token, to swap an authorization grant for an access token, or to swap a refresh token for a new access token. There are two types of access tokens - user tokens and client tokens. <br/><br/>A client token authenticates a specific client, e.g. your architecture and servers. client tokens can be used to access any resources owned by the client, such as general information on users your client has created. Client tokens are also required to register new users or make requests on their behalf such as the user posting a receipt. <br/><br/>A user token authenticates a specific user to our system, e.g. Jane Doe of Winnipeg, Manitoba. A user token will be required if you want to access specific data about a user, such as the details of that user's documents. <br/><br/>Token expiry information is in the `expires_in` and `refresh_expires_in` fields. <br/><br/>You can also retrieve the expiration times for user and client access tokens using the user GET endpoint, `/users/:userID`, and the clientInfo GET endpoint, `/clientInfo`, respectively. <br/><br/>No matter which kind of access token is being requested, the client MUST include their Client Key and Client Secret as the username and password, respectively, in the HTTP Authorization header, on top of providing required parameters below. <br/><br/>This can be accomplished by setting a 'basic' authentication header using the Client Key and Client Secret as username and password like shown below: <br/><br/>`Authorization: 'Basic base64(ClientKey:ClientSecret)'` <br/><br/>The access token is currently always a bearer token, which should be sent in the 'Authorization' header in the format 'Bearer accessToken'. <br/><br/>In the future, other token types may also be used, so please check the `token_type` provided in the response. <br/><br/>For an example, please refer to <a href='./apiref/demo.html#step_six'>'Authentication Step Six' of the jQuery Demo</a>. <br/><br/>The response also returns a `token_id`. This can not be used for authenticating regular requests, but is required for using our query parameter based signature method. Responses:
200: Success. The access token was created successfully.
400: Bad Request. This will occur if you omit a required parameter, or if you provide an invalid value for a required parameter. It can also occur if you put in the wrong Redirect URI, for example, if you put one that doesn't match what you provided when you made the authorization grant request.
401: Unauthorized. This will occur if the client key/secret you have provided is invalid.
Return
Parameters
This is the type of authentication the client is presenting for its access-token. <br/><br/>If the client is looking for a client-token, then this should be set to 'client_credentials'. <br/><br/>If the client is looking to swap an authorization grant for an access token, this should be set to 'authorization_code' <br/><br/>If the client is looking to swap a refresh_token for a new access token, this should be set to 'refresh_token'
If the client is swapping an authorization code for an access token, then this argument is required. If you are just obtaining a client token directly, you do not need to provide a redirect_uri. This must be the same redirect_uri that was provided to the authorizationGrant endpoint, and must also match the redirect_uri which was registered with your client when you received your client credentials.
If the client is swapping an authorization code for an access token, then this argument is required. If you are just obtaining a client token directly, you do not need to provide a code. This parameter is the authorization_code which you obtained when you used the `/authorizationGrant` endpoint.
If the client is swapping a refresh_token for an access token, then this argument is required. Otherwise, this parameter should be omitted. This parameter is the refresh_token which you obtained when you last used the `/accessToken` endpoint.
Access Token Request