Prerequisites

Retrieving an access Token

The Workflow API uses OAuth 2.0 authentication with the authorization code grant type. At the end of the Oauth authentication code flow, you’ll get a user access token that you’ll pass in a header with each API request.

1

Configure a redirect URI

You can configure one (or multiple) redirect URIs in the Zapier Developer Platform under EmbedSettingsRedirect URIs

You will only be able to configure redirect URIs after you’ve published your app as a public integration in Zapier’s App Directory.

2

Get your Client ID and Client Secret

You can find your Client ID and Client Secret in the Zapier Developer Platform under EmbedSettingsCredentials

Your application’s Client ID and Client Secret are only available after you’ve published your app as a public integration in Zapier’s App Directory.

Regenerating your client secret will invalidate any previous secret.

3

Determine which OAuth scopes are required for your use case

The various endpoints of the Zapier Workflow API require different OAuth scopes. Information on specific scopes required is included within the API reference for each endpoint.

4

Initiate the OAuth flow and get the user's permission.

Construct a URL like the one below (with your own redirect url, client id, OAuth scopes, etc.) and open a browser to that URL.

https://api.zapier.com/v2/authorize
    ?response_type=code
    &client_id={YOUR_CLIENT_ID}
    &redirect_uri={YOUR_REDIRECT_URI}
    &scope={YOUR_OAUTH_SCOPES}
    &response_mode=query
    &state={RANDOM_STRING}

Here’s an explaination for each query parameter:

ParameterMeaning
response_type=codeThis tells the authorization server that the application is initiating the authorization code flow.
client_idThe public identifier for your application. This will be the same client id that you retrieved in step #2.
redirect_uriTells Zapier’s authorization server where to send the user back to after they approve the request. This should be the redirect URI that you configured in step #1.
scopeOne or more space-separated strings indicating which permissions your application is requesting. Information on specific scopes required is included within the API reference for each endpoint.
stateYour application generates a random string and includes it in the request. It should then check that the same value is returned after the user authorizes the app. This is used to prevent CSRF attacks.

A full example would be:

https://api.zapier.com/v2/authorize
  ?response_type=code
  &client_id=5672067294567789354752
  &redirect_uri=https%3A%2F%2Fyour-app.com%2Fcallback
  &scope=zap%20zap:write%20authentication
  &response_mode=query
  &state=tney4952

When the user visits this URL, Zapier’s authorization server will present them with a prompt asking if they would like to authorize your application’s request.

5

Receive a Redirect at your Redirect URI

If the user approves the above request, then Zapier’s authorization server will redirect the browser back to the redirect_uri that you specified and configured earlier. Two query string parameters, code and state will also be included.

For example, the browser would be redirected to:

https://your-app.com/redirect
?code=dfJ2KuL0vKLRCwQIOL5NDGKQ&H9mlc
&state=tney4952
ParameterMeaning
codeThis value is the authorization code generated by Zapier’s authorization server. In the next step, you’ll exchange this code for an access token. Keep in mind that authorization codes are only valid for 2 minutes, and you’ll need to do the exchange within that window of time to avoid errors.
stateThis value should match the state query parameter that you used in step 2. Your application should verify that these values match.
6

Exchange authorization code for an access token

The final step is to exchange the authorization code that you just recieved for an access token that can be used to make authorized requests to the Zapier Workflow API. You make the exchange with a POST request to Zapier’s token endpoint https://zapier.com/oauth/token/.

Below is an example of a request that can be used to do the exchange.

ParameterMeaning
CLIENT_IDThis will be the same client id that you retrieved in step #2.
CLIENT_SECRETThis is a secret known only to your application and the authorization server. It will be the same client secret that you retrieved in step #2.
AUTHORIZATION_CODEThis is the authorization code you received in the above step #5.
REDIRECT_URIThis should be the redirect URI that you configured in step #1.

Note that, in addition to client id and secret being passed as a Basic Authentication header as above, they can be passed as part of the body, using the keys client_id and client_secret.

You’ll recieve a response that looks like this:

HTTP/1.1 200 OK
Content-Type: multipart/form-data
Cache-Control: no-store
Pragma: no-cache

{
  "access_token": "jk8s9dGJK39JKD93jkd03JD",
  "expires_in": 36000,
  "token_type": "Bearer",
  "scope": "zap zap:write authentication",
  "refresh_token": "9D9oz2ZzaouT12LpvklQwNBf6s4vva"
}
This response contains the access_token that you’ll use to make API request on the user’s behalf, as well as a refresh token.

Both tokens should be stored securely, to protect your users’ privacy.

The refresh token in particularly important, since it would allow a nefarious entity to generate access tokens indefinitely:

  • The refresh token MAY NOT be stored in localStorage
  • The refresh token MAY NOT be stored in sessionStorage
  • The refresh token MAY NOT be stored in indexedDB
  • The refresh token MAY NOT be stored in a regular cookie
  • The refresh token MAY be stored in a Secure; HTTPOnly cookie
  • The refresh token MAY be stored in a server side database, only accessible to the current user
7

Using the access token

The access token should be passed with requests as an Authorization header. For example:

Authorization: Bearer jk8s9dGJK39JKD93jkd03JD
8

Refreshing the access token

All access tokens will expire after 10 hours (the number of seconds in expires_in), for security purposes. After that point, any request using that access token will return a 401 status code. To proceed, the refresh token should be exchanged for a new access token and a new refresh token. This will not require any interaction by the user.

Below is an example request that can be used:

ParameterMeaning
CLIENT_IDThis will be the same client id that you retrieved earlier.
CLIENT_SECRETThis is a secret known only to your application and the authorization server. It will be the same client secret that you retrieved earlier.
REFRESH_TOKENThis is the refresh token code you received with the access token.

You’ll receive a response that looks like this:

HTTP/1.1 200 OK
Content-Type: multipart/form-data
Cache-Control: no-store
Pragma: no-cache
{
  "access_token": "NEfSRKpUjVd3Nj9yyaXKs15BrM7SVA",
  "expires_in": 36000,
  "token_type": "Bearer",
  "scope": "zap zap:write authentication",
  "refresh_token": "zzdumGAW2TmayeKjzu0z9oHJiziKdn"
}

Note that you will receive a new refresh token - the old refresh token can no longer be used again, and so the new refresh token should be stored securely for future use. Refresh tokens don’t have an expiration date - they only expire when they are used to get a new access token.

Retrieving your client id

The previous version of the Workflow API (the PartnerAPI) supports passing the client_id to make an authenticated request.

1

Get your client id

You can find your client id in the Zapier Developer Platform under EmbedSettingsCredentials

Your application’s Client ID and Client Secret are only available after you’ve published your app as a public integration in Zapier’s App Directory.

Regenerating your client secret will invalidate any previous secret.

2

Pass the client id as a query parameter

From there, simply pass your client_id as a query param to any V1 endpoints that require it.

Example for Zap-templates
    https://api.zapier.com/v1/zap-templates?client_id={YOUR_CLIENT_ID}