Authenticating with Data Connectors

Note: This page explains how to provide authentication for data connectors in the Transposit Dev Platform. If you are using Transposit workflows, you will authenticate your integration in Settings > Integrations and follow the instructions for the specific integration.

Auth via OAuth 2.0 #

Given OAuth settings (i.e. client IDs and secrets), Transposit will automatically handle the OAuth 2.0 authentication flow to procure an access token and refresh as needed. For most data connections that require OAuth, Transposit provides these settings for limited use. For these data connections, no further setup is required for authorization after the connection is added.

Custom OAuth settings #

If you do not want to use the Transposit-provided OAuth settings, you always have the option to overwrite the configuration with your own custom OAuth settings. A small subset of data connections will require you to provide custom OAuth settings because no feasible Transposit-provided OAuth settings exist for those connections.

To use your own client ID and secret:

  • Set up a developer app using the connector's platform. Add as a Redirect URI.
  • Go to Code > Data Connections in Transposit and select your data connector.
  • Under Authentication > Configure, add the client ID and secret from your created developer app.
  • Delete any keys already stored for this data connector. For development, go to Code > Auth & settings > Keys. Disconnect the key and then connect again to use your client ID and secret. For production, go to Deploy > Production Keys and repeat this process.

The following connectors require custom OAuth settings. When you add the connector to your service, you will be prompted to add these settings. Follow the links to create your own developer apps:

Below are links to create developer apps (to generate your own OAuth settings) if you do not want to use the Transposit-provided settings:

Generating a client ID and secret with Google connectors #

  • Go to the Google Cloud Platform Console and select a project or create a new one.
  • Select APIs & services > Credentials.
  • Click Create Credentials > OAuth Client ID.
  • Either configure a consent screen if this is your first time, or modify your existing consent screen to add as an authorized domain.
  • Select Web application.
  • Note the Client ID and Client Secret to be used in the next step, and click Save.
  • Select the credential you just created and add as an authorized redirect URI. If you did not properly set up your authorized domain in your consent screen, you may get an Invalid Redirect error when adding the key in the Tranposit console. If so, follow the link and add to the authorized domains list.
  • Go to APIs & Services > Library, search for the API you want to use (e.g. Google Mail, Google Calendar, or Google Drive), and enable it.

If you would like others to use your application, you may need to get it verified by Google.

Custom OAuth scope #

The scope of a data connector defines what permissions your users will be allowing your app. By default, the range of scopes for each data connector is fairly permissive. You can add or remove scopes for your data connectiors as you see fit.

Auth via header parameters #

For data connections that implement authentication with header parameters, such as PagerDuty, the header parameter name (as documented by the external API site) and header parameter value (typically a secret token distributed by the external API site) must be provided when adding the connection to an application.

Example: PagerDuty

PagerDuty auth example

Auth via query parameters #

For data connections that implement authentication with query parameters, such as Zoom, only the query parameter value (typically a secret distributed by the external API site) must be provided when adding the connection to an application.

Example: Zoom

Zoom auth example

Auth via AWS parameters #

For AWS data connections, such as Lambda, the required combination of authentication parameters 'Access Key', 'Secret Key', and 'Role' depends on the authentication setup of your particular AWS service being connected to. The pair of 'Access Key' and 'Secret Key' authenticates you as an IAM user, and the 'Role' can be used to specify the ARN of an IAM role.

Example: Lambda with all three parameters provided (i.e. authentication as an IAM user assuming an IAM role)

Lambda auth example

  • AWS Basic
  • Elastic
  • Lambda