Authentication
Last updated
Was this helpful?
Last updated
Was this helpful?
Once you have a Client ID and Client Secret, the next step to making requests to the Pitchly API is to generate an access token that you can use to authenticate requests.
While your Client ID and Client Secret will generally remain the same for a long period of time, access tokens are usually short-lived. This makes your requests more secure.
Different types of access tokens can be generated for different types of use cases. Find your use case below and follow its instructions to learn how to generate an access token.
This is the most common use case for customers who want to access their own data via Pitchly’s API. Generating an access token for this use case is also the most straightforward.
The access token in this case is a JSON Web Token (JWT) containing your Client ID and is signed with your Client Secret. Optionally, you may also set an expiry time on the token, specify which workspaces the token will provide access to, and specify which permissions the token will have.
Choose your specific use case below:
This use case is the most common in situations where users log into your app, and you want to make API requests to Pitchly after the user has connected their Pitchly account.
In this section, you will learn how to authorize a user against Pitchly using OAuth to ultimately acquire an access token that can be used to make API requests against Pitchly.
Once the user is in your app, the first step is to redirect them to our authorization page. The URL will take the following format:
Click on each section below to learn how to populate each variable:
After the user successfully authorizes your app to access their Pitchly data, we will redirect the user to your redirect_uri
with a code
in the URL query parameters. This code is only valid for a short time and must be exchanged for an access token.
To exchange this code for an access token, you will need to make a POST request to our token endpoint. See the details of that request below.
POST
https://platform.pitchly.com/api/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type*
String
"authorization_code"
code*
String
The code
you received
redirect_uri*
String
code_verifier*
String
client_id*
String
The client_id
of your app
client_secret*
String
scope
String
A space-delimited list of downscoped permissions you want the resulting access token to have. Note that you can only request the access token have fewer permissions than approved by the organization admin, not more.
workspace_ids
String
A space-delimited list of downscoped workspaces you want the resulting access token to have access to. Note that you can only request the access token have access to fewer workspaces than approved by the organization admin, not more.
Where you make this request from will depend on the capabilities of your app. Choose your app type below:
Access tokens are only valid for one hour. If you want to continue to access the user's Pitchly data after that time, you will need to get a new access token. You have two options to do that:
The remainder of these instructions will focus on option #2.
POST
https://platform.pitchly.com/api/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type*
String
"refresh_token"
refresh_token*
String
The stored refresh_token
client_id*
String
The client_id
of your app
client_secret*
String
scope
String
A space-delimited list of downscoped permissions you want the resulting access token to have. Note that you can only request the access token have fewer permissions than approved by the organization admin, not more.
workspace_ids
String
A space-delimited list of downscoped workspaces you want the resulting access token to have access to. Note that you can only request the access token have access to fewer workspaces than approved by the organization admin, not more.
What do you do if you want to access data in an organization that has installed your app but your app doesn’t have a user interface to allow users to sign in, or you simply want to get data from the organization at any time, regardless of whether a user has signed in recently?
Some examples may include:
An analytics app that emails you statistics on your account periodically.
An image tracker that notifies you of images in your tables that are copyrighted.
An integration to an outside system that syncs your data automatically.
This is where the client_credentials
grant can come in handy. To get an access token using this grant, make the following request.
POST
https://platform.pitchly.com/api/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type*
String
"client_credentials"
organization_id*
String
The organization you want to access data from
client_id*
String
The client_id
of your app
client_secret*
String
The client_secret
of your app
scope
String
A space-delimited list of downscoped permissions you want the resulting access token to have. Note that you can only request the access token have fewer permissions than approved by the organization admin, not more.
workspace_ids
String
A space-delimited list of downscoped workspaces you want the resulting access token to have access to. Note that you can only request the access token have access to fewer workspaces than approved by the organization admin, not more.
Using the returned access token (which we call an “install access token”), you may now make API calls to the desired organization on behalf of your app itself instead of on behalf of a specific user.
Install access tokens will have access to all workspaces the organization approves the app to access. User access tokens, in contrast, only have access to an intersection of workspaces the app has been approved access to + the workspaces the current user is a member of.
Install access tokens will not have access to anything that is private to a specific user, such as private views.
Keep these factors in mind if you plan to use a combination of user access tokens and install access tokens throughout your app, since one won't necessarily have access to the same resources as the other.
Now that you have an access token, you can make API calls against our GraphQL API. Click the link below to learn how.
Below are all possible permissions an app can have. The workspaces an app can access will depend on which workspaces the admin of the requested organization approves the app to access, as well as the type of access token that is generated.
records:create
Create records in workspaces
records:update
Update records in workspaces
records:delete
Delete records in workspaces
workspace_members:read
Read members of workspaces
teams:read
Read teams across the organization
documents:read
Read content and templates in the Elements app
table:create
Create a new table in a workspace
table:modify
Modify table dropdown field choices
rootTable:create
Create a table in the organization
This is the Redirect URL you gave us prior to registering your app. If you did not provide one, please so that we can register it with your app.
The Redirect URL must be the URL you wish to redirect users to after they have authorized your app with Pitchly. When we redirect to it, we will append a code
to its query parameters, which you will eventually .
When we redirect the user back to your app, we will append the state
you gave us to the URL as a query parameter. Verify that this state
parameter matches the value you have stored in cookies, session, or localstorage. If it matches, it means this is a valid request. If it doesn't match, it means this request was either unsolicited or forged, and you should not continue to the .
While verifies that the same user who initiated the redirect from your app to Pitchly is the same user who returns to your app after we redirect back, the code_challenge
parameter solves a similar but different problem.
We want to verify that the same user who initiated the redirect from your app to Pitchly is also the same user who ultimately attempts to exchange the returned code
for an access token (which we will cover in the ).
To do this, we use a common standard called "" (pronounced "pixie"), which stands for "Proof Key for Code Exchange". This is an extension of the OAuth standard and aims to prevent forgery attacks.
Below is browser code (without dependencies) that can be used to generate your code_challenge
and store your code_verifier
in localstorage. Note that the generateRandomString
function has been carried over from the state
code example .
Later, when the user returns to your app and you send us a request to exchange the returned code
for an access token (which we will cover in the ), you will pass the code_verifier
from localstorage to that request. So hold onto it until you have an access token!
The same redirect_uri
that was sent in
The code_verifier
that was created in the process of generating the in step 1
The client_secret
of your app. This is required unless your app is a public client - i.e. an SPA, Mobile, or Desktop app that cannot keep a secret. .
The response will include an access_token
, refresh_token
(which you can use to once this one expires), how long the access token will be valid for in seconds via expires_in
, and a space-delimited list of permissions this access token has via scope
. Note that refresh tokens will remain valid until they are used.
Also note: It's safest to store both the resulting access_token
and refresh_token
you receive behind your server and proxy API calls using the access token via your server. But if you need to make API calls client side using the access token, you can do so as long as the access token is only shared with the user the access token is for. But remember: the access token will carry the full permissions the admin of the organization approved for your app unless you've requested the access token have fewer permissions. This means it is possible that the access token can do things that the user wouldn't normally be able to; for example, create or update records while the user only has read privilege. To counter this, you can either downscope the access token permissions by providing the option in your or proxy API calls through your server.
that your app is a public client, so we can register it accordingly.
If you are making the request from a browser, the page origin that initiated the request must match one of the origins in the list of valid you gave us. if you need us to update your list of Redirect URLs.
Redirect the user back through the OAuth flow again (starting from ).
Get a new access token using the refresh_token
provided in the .
Assuming you have held onto the refresh_token
returned in the , you can acquire a new access token by making the following request.
The client_secret
of your app. This is required unless your app is a public client - i.e. an SPA, Mobile, or Desktop app that cannot keep a secret. .
Response is identical to the , except you will receive a new access_token
and a new refresh_token
. Note that the old refresh token will be immediately invalidated, so you will want to replace the old refresh token with this one, so that you can get a new access token again once this one expires. The new refresh token will remain valid up until it is used to get a new access token again.
Just like in , if your app has a server backend and can keep a secret, you must include your client_secret
in the request. If your app cannot keep a secret, you must exclude the client_secret
from the request.
Each time your access token expires, you can repeat this step again to get a new access token. If this request fails, you can redirect the user back through the OAuth flow (from ) to try to get an access token again. This can happen if the organization has uninstalled your app and it must be approved again.
Most apps generally fall into one of the two use cases listed above. But if you’re trying to get data from an organization other than your own, the carries one significant limitation: it requires a user.
Unlike the response you receive for a , this response will not include a refresh_token
. Once this access token expires, you can get a new one by simply making this request again.
Compared to , note that install access tokens will differ in the following ways: