This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
If the API that you are working with requires you to sign or authenticate your requests, it may utilize an implementation of OAuth 2.0 or another authentication method to show that you have the access needed to consume the web service. There are some key words that you can look for in the API documentation that you are using that will help you quickly choose the appropriate grant flow to use in Alteryx. Below is a list of many of the authentication methods you may encounter, along with whether they do or do not lend themselves to being used within an Alteryx workflow.
If the authentication method being implemented requires you to first grant authorization in order to receive an access token, that should be one of the very first steps of your process. This would involve you taking in the required set of credentials, and then passing that to the authorization service in order to exchange it for the token that will be used to authenticate your requests. If you are dependent on a response from an authorization service that contains the access token, you will need to parse the value out of the response and pass it to subsequent API calls that require it. If working with something like an API Key, or Basic authentication, you only need to do what is necessary to prepare the key, and then use it in the workflow in the appropriate place, either as a header or as a parameter on the query/payload.
API Key - If working with a service that requires you to authenticate your requests with an API key, this can be added as a parameter to your query/payload.
The implementation of this usually looks like [clientid:clientsecret] or [username : password] base 64 encoded and then prepended with "Basic" as the value for the header "Authorization".
In your workflow, you can take in the client id and secret or username and password, and use the Formula tool to prepare the string for encoding. You can then use the base 64 encoder to encode the string, add “Basic” to the encoded string, and then use that as the value for an “Authorization” header in your Download tool
OAuth - When working with an OAuth (1.0 or 2.0) grant flow, it is very important to look for an endpoint or method to send your client id/secret, or username/password to, in exchange for an authorization code or access token. This helps you avoid getting caught up in any grant flows that require you to redirect to another site or accept incoming HTTP requests in order to complete the authorization process. Working with one of these types of grant flows most often requires you to create/register an application with the service as well, which is then used to authenticate you as the client to the service. Keep this in mind when reviewing the API documentation, since implementation of this can vary by service.
OAuth 1.0 - The initial implementation of OAuth provisions a few methods for authorization listed below. To read more about OAuth 1.0-view the RFC.
Temporary Credentials - Requires a redirect URI, does not lend itself to Alteryx workflows.
Resource Owner Authorization - Can be used within Alteryx workflows.
Token Credentials - Can be used within Alteryx workflows.
OAuth 2.0 - This spec provides many ways to obtain authorization, explained below, and then that authorization grant is then used to exchange for an access code/token to sign your requests with. To read more about OAuth2.0-view the RFC.
Authorization Code Grant - Requires a redirect URI, does not lend itself to Alteryx workflows.
Implicit Grant - Requires a redirect URI, does not lend itself to Alteryx workflows.
Resource Owner Password Credentials Grant - Can be used within Alteryx workflows.
Client-Credentials Grant - Can be used within Alteryx workflows.