Connect a GraphQL API

Learn how to connect GraphQL APIs to Retool.

Version: Cloud and 3.178 Edge

You can use the GraphQL integration to create a resource and make it available in Retool. Once complete, your users can write queries that interact with GraphQL data.

Requirements

The GraphQL integration requirements depend on whether you have a cloud-hosted or self-hosted Retool organization. You may also need to make GraphQL configuration changes before creating the resource.

Cloud-hosted organizations

Sufficient user permissions to create resources

All users for Retool organizations on Free or Team plans have global Edit permissions and can add, edit, and remove resources. If your organization manages user permissions for resources, you must be a member of a group with Edit all permissions.

Allow Retool to access the data source

If the data source is behind a firewall or restricts access based on IP address, then you must ensure that your Retool organization can access it. If necessary, configure your data source to allow access from Retool's IP addresses.

CIDR IP addresses

3.77.79.248/30
35.90.103.132/30
44.208.168.68/30

Individual IP addresses

3.77.79.249
3.77.79.250
35.90.103.132
35.90.103.133
35.90.103.134
35.90.103.135
44.208.168.68
44.208.168.69
44.208.168.70
44.208.168.71

Retool is building support for querying firewalled resources without allowlisting Retool’s IP address. To learn more or be considered for early access, contact cloud-connect@retool.com.

GraphQL settings and authentication

You must have sufficient access and familiarity with your GraphQL data source so you can provide:

• Required connection settings (e.g., URL and server variables).
• Authentication credentials (e.g., API keys).

In some cases, you may need to make changes to your GraphQL configuration, such as generating authentication credentials or allowing access through a firewall. Refer to the configuration and authentication sections to learn more.

Self-hosted organizations

Sufficient user permissions to create resources

All users for Retool organizations on Free or Team plans have global Edit permissions and can add, edit, and remove resources. If your organization manages user permissions for resources, you must be a member of a group with Edit all permissions.

Allow your deployment to access the data source

Your self-hosted deployment must have access to the data source. Ensure that any potential firewall rules for either the data source or your deployment instance are updated to allow them to communicate.

GraphQL settings and authentication

You must have sufficient access and familiarity with your GraphQL data source so you can provide:

• Required connection settings (e.g., URL and server variables).
• Authentication credentials (e.g., API keys).

In some cases, you may need to make changes to your GraphQL configuration, such as generating authentication credentials or allowing access through a firewall. Refer to the configuration and authentication sections to learn more.

Configure the resource

Sign in to your Retool organization and navigate to the Resources tab. Click Create new > Resource, then select GraphQL.

Configuration

Specify the name, location, and description to use for your GraphQL resource. Retool displays the resource name and type in query editors to help users identify them.

Provide the following configuration settings to create the resource. Depending on how your data source is configured, you may also need to provide optional settings for Retool to connect.

Cloud-hosted organizations

Base URL

The base URL for all requests (e.g., https://example.com).

URL parameters

Additional URL parameters to include with all requests.

Headers

Additional headers to include with all requests.

Exclude default headers

Whether to exclude the default User-Agent header that identifies the request as coming from Retool.

Sanitize custom headers

Whether to sanitize additional custom headers.

Body

Additional key-value pairs to include within the body of all requests.

Cookies

Cookies to use for cookie-based APIs.

Use the pattern COOKIE_your_cookie_name in the Headers section to implement the double-cookie submit pattern.

Forward all cookies

Whether to forward all cookies.

Use self-signed certificates

Whether to allow self-signed certificates.

Disable introspection

Whether to disable introspection for APIs that do not support this feature.

Override default outbound Retool region

Retool connects to your data source from the us-west-2 region. Choosing a different outbound region can improve performance through geographic proximity.

Region	Location
us-west-2	US West (Oregon)
eu-central-1	Europe (Frankfurt, Germany)
ap-southeast-1	Asia-Pacific (Singapore)

Self-hosted organizations

Base URL

The base URL for all requests (e.g., https://example.com).

URL parameters

Additional URL parameters to include with all requests.

Headers

Additional headers to include with all requests.

Exclude default headers

Whether to exclude the default User-Agent header that identifies the request as coming from Retool.

Sanitize custom headers

Whether to sanitize additional custom headers.

Body

Additional key-value pairs to include within the body of all requests.

Cookies

Cookies to use for cookie-based APIs.

Use the pattern COOKIE_your_cookie_name in the Headers section to implement the double-cookie submit pattern.

Forward all cookies

Whether to forward all cookies.

Use self-signed certificates

Whether to allow self-signed certificates.

Disable introspection

Whether to disable introspection for APIs that do not support this feature.

Authentication

The GraphQL integration supports the following authentication methods. Depending on which authentication method you use, you may need to make changes to your GraphQL configuration.

Cloud-hosted organizations

Auth0

Authentication is performed using an Auth0 client application. You must create this application and then provide the details.

Credential	Description
Domain	The domain URL.
Client ID	The client ID.
Client secret	The client secret.
Audience	The audience URL.

AWS Identity and Access Management

Authentication is performed using the provided AWS security credentials. You must be able to obtain and provide these credentials to create the resource.

Region

The AWS region with which to connect (e.g., us-east-1). This is often part of the base URL.

Region	Location
us-east-1	US East (N. Virginia)
us-east-2	US East (Ohio)
us-west-1	US West (N. California)
us-west-2	US West (Oregon)
af-south-1	Africa (Cape Town)
ap-east-1	Asia Pacific (Hong Kong)
ap-northeast-1	Asia Pacific (Tokyo)
ap-northeast-2	Asia Pacific (Seoul)
ap-northeast-3	Asia Pacific (Osaka)
ap-south-1	Asia Pacific (Mumbai)
ap-south-2	Asia Pacific (Bahrain)
ap-southeast-1	Asia Pacific (Singapore)
ap-southeast-2	Asia Pacific (Sydney)
ap-southeast-3	Asia Pacific (Jakarta)
ap-southeast-4	Asia Pacific (Hong Kong)
ca-central-1	Canada (Central)
eu-central-1	Europe (Frankfurt)
eu-central-2	Europe (Warsaw)
eu-north-1	Europe (Stockholm)
eu-south-1	Europe (Milan)
eu-south-2	Europe (London)
eu-west-1	Europe (Ireland)
eu-west-2	Europe (London)
eu-west-3	Europe (Paris)
me-central-1	Middle East (Bahrain)
me-south-1	Middle East (Bahrain)
sa-east-1	South America (São Paulo)
us-gov-east-1	AWS GovCloud (US-East)
us-gov-west-1	AWS GovCloud (US-West)

Access key ID

The access key ID with which to authenticate.

Secret key ID

The secret key ID with which to authenticate.

Role to assume (ARN)

A different role to use for accessing the API.

Basic

Authentication is performed using Basic HTTP authentication with a username and password. You must be able to obtain and provide these credentials to create the resource.

Bearer Token

Authentication is performed using Bearer HTTP authentication with a token. You must be able to obtain and provide these credentials to create the resource.

Digest

Authentication is performed using Digest HTTP authentication with a username and password. You must be able to obtain and provide these credentials to create the resource.

Google service account

Authenticate with a service account tied to a Google Cloud project. This method allows users to give Retool access to certain APIs or data with the service account's email address.

Retool recommends using service account authentication when you need to share credentials across users but limit Retool's access to a subset of data. This authentication flow restricts Retool's access to APIs or data shared with the service account email address only.

Refer to Google's service account documentation to learn more.

OAuth 1.0

Authentication is performed using an OAuth 1.0 client application. You must create this application and then provide the details.

Credential	Description
Consumer key	The consumer key with which to authenticate.
Consumer secret	The consumer secret with which to authenticate.
Access token	The access token with which to authenticate.
Token secret	The access token secret.
Realm	The realm to use.
Signature method	The signature method to use. Either HMAC-SHA1, HMAC-SHA256, or PLAINTEXT.

Custom OAuth 2.0 client credentials

Authentication is performed using a custom OAuth 2.0 client app. You must create this client and then provide its credentials. Once configured, your users are redirected to to sign in and authorize Retool to access data.

OAuth apps typically require the following values during creation:

• OAuth callback URL: The URL to which users are redirected once they have successfully signed in.
• Scopes : The permissions granted to Retool. Each scope defines a specific set of permissions (e.g., messages:read to read messages users:write to create new users). You must ensure that any scopes defined in your OAuth app matches the scopes you specify when configuring the resource.

Once you've created an OAuth app you can obtain its credentials, such as the Client ID and Client secret. You then provide these to configure Retool for OAuth authentication.

Refer to the documentation for detailed instructions on creating an OAuth app.

Authorization URL

The URL with which to authenticate.

Access token URL

The access token URL.

Client ID

The client ID with which to authenticate.

Client secret

The client secret with which to authenticate.

Scopes

Scopes govern what permissions Retool has once you connect your account authenticates. For some integrations, Retool automatically populates a set of recommended scopes to make full use of the integration. In some cases, you may need to specify the scopes for Retool to use.

Prompt

The type of prompt when users authenticate.

Value	Description
None	Attempt to authorize silently without using a prompt.
Consent	Prompt the user to consent.
Login	Require the user to sign in with the provider, regardless of whether they are currently signed in.
Select account	Require the user to select an account if they could be signed into multiple accounts.
No prompt	Do not display a prompt.

Audience

The OAuth 2.0 audience.

Enable an auth verification endpoint

Whether to use a custom authentication verification URL.

If enabled, you can provide an endpoint that will return a response code in the range 200-299 when the user is authenticated, and a non-2xx status code (e.g., 401 Unauthorized) when the user is not authenticated.

Skip Retool consent screen and attempt login

Whether to skip the Retool consent screen at the start of the authentication flow.

Access token lifespan

The lifespan of the access token before it expires.

Session-based

Session-based authentication has been deprecated. Use an alternative authentication method, if available.

Authentication is performed using session-based authentication. You must be able to obtain and provide these credentials to create the resource.

Credential	Description
Cookies to forward	The cookies to forward.
Enable an auth verification endpoint	Whether to use a verification endpoint to determine if the user needs to authenticate.
URL to link to for logging in	The URL with which users can authenticate.

Self-hosted organizations

Auth0

Authentication is performed using an Auth0 client application. You must create this application and then provide the details.

Credential	Description
Domain	The domain URL.
Client ID	The client ID.
Client secret	The client secret.
Audience	The audience URL.

AWS Identity and Access Management

Authentication is performed using the provided AWS security credentials. You must be able to obtain and provide these credentials to create the resource.

Credential provider chain

Authentication is performed using AWS credentials sourced from the credential provider chain. Use this option to authenticate with credentials provided in environment variables or the underlying instance role.

Region

The AWS region with which to connect (e.g., us-east-1). This is often part of the base URL.

Region	Location
us-east-1	US East (N. Virginia)
us-east-2	US East (Ohio)
us-west-1	US West (N. California)
us-west-2	US West (Oregon)
af-south-1	Africa (Cape Town)
ap-east-1	Asia Pacific (Hong Kong)
ap-northeast-1	Asia Pacific (Tokyo)
ap-northeast-2	Asia Pacific (Seoul)
ap-northeast-3	Asia Pacific (Osaka)
ap-south-1	Asia Pacific (Mumbai)
ap-south-2	Asia Pacific (Bahrain)
ap-southeast-1	Asia Pacific (Singapore)
ap-southeast-2	Asia Pacific (Sydney)
ap-southeast-3	Asia Pacific (Jakarta)
ap-southeast-4	Asia Pacific (Hong Kong)
ca-central-1	Canada (Central)
eu-central-1	Europe (Frankfurt)
eu-central-2	Europe (Warsaw)
eu-north-1	Europe (Stockholm)
eu-south-1	Europe (Milan)
eu-south-2	Europe (London)
eu-west-1	Europe (Ireland)
eu-west-2	Europe (London)
eu-west-3	Europe (Paris)
me-central-1	Middle East (Bahrain)
me-south-1	Middle East (Bahrain)
sa-east-1	South America (São Paulo)
us-gov-east-1	AWS GovCloud (US-East)
us-gov-west-1	AWS GovCloud (US-West)

Access key ID

The access key ID with which to authenticate.

Secret key ID

The secret key ID with which to authenticate.

Role to assume (ARN)

A different role to use for accessing the API.

Basic

Authentication is performed using Basic HTTP authentication with a username and password. You must be able to obtain and provide these credentials to create the resource.

Bearer Token

Authentication is performed using Bearer HTTP authentication with a token. You must be able to obtain and provide these credentials to create the resource.

Digest

Authentication is performed using Digest HTTP authentication with a username and password. You must be able to obtain and provide these credentials to create the resource.

OAuth 1.0

Authentication is performed using an OAuth 1.0 client application. You must create this application and then provide the details.

Credential	Description
Consumer key	The consumer key with which to authenticate.
Consumer secret	The consumer secret with which to authenticate.
Access token	The access token with which to authenticate.
Token secret	The access token secret.
Realm	The realm to use.
Signature method	The signature method to use. Either HMAC-SHA1, HMAC-SHA256, or PLAINTEXT.

Custom OAuth 2.0 client credentials

Authentication is performed using a custom OAuth 2.0 client app. You must create this client and then provide its credentials. Once configured, your users are redirected to to sign in and authorize Retool to access data.

OAuth apps typically require the following values during creation:

• OAuth callback URL: The URL to which users are redirected once they have successfully signed in.
• Scopes : The permissions granted to Retool. Each scope defines a specific set of permissions (e.g., messages:read to read messages users:write to create new users). You must ensure that any scopes defined in your OAuth app matches the scopes you specify when configuring the resource.

Once you've created an OAuth app you can obtain its credentials, such as the Client ID and Client secret. You then provide these to configure Retool for OAuth authentication.

Refer to the documentation for detailed instructions on creating an OAuth app.

Authorization URL

The URL with which to authenticate.

Access token URL

The access token URL.

Client ID

The client ID with which to authenticate.

Client secret

The client secret with which to authenticate.

Scopes

Scopes govern what permissions Retool has once you connect your account authenticates. For some integrations, Retool automatically populates a set of recommended scopes to make full use of the integration. In some cases, you may need to specify the scopes for Retool to use.

Prompt

The type of prompt when users authenticate.

Value	Description
None	Attempt to authorize silently without using a prompt.
Consent	Prompt the user to consent.
Login	Require the user to sign in with the provider, regardless of whether they are currently signed in.
Select account	Require the user to select an account if they could be signed into multiple accounts.
No prompt	Do not display a prompt.

Audience

The OAuth 2.0 audience.

Enable an auth verification endpoint

Whether to use a custom authentication verification URL.

If enabled, you can provide an endpoint that will return a response code in the range 200-299 when the user is authenticated, and a non-2xx status code (e.g., 401 Unauthorized) when the user is not authenticated.

Skip Retool consent screen and attempt login

Whether to skip the Retool consent screen at the start of the authentication flow.

Access token lifespan

The lifespan of the access token before it expires.

Session-based

Session-based authentication has been deprecated. Use an alternative authentication method, if available.

Authentication is performed using session-based authentication. You must be able to obtain and provide these credentials to create the resource.

Credential	Description
Cookies to forward	The cookies to forward.
Enable an auth verification endpoint	Whether to use a verification endpoint to determine if the user needs to authenticate.
URL to link to for logging in	The URL with which users can authenticate.

Test the connection

Click Test Connection to verify that Retool can successfully connect to the data source. If the test fails, check the resource settings and try again.

Testing a connection only checks whether Retool can successfully connect to the resource. It cannot check whether the provided credentials have sufficient privileges or can perform every supported action.

Save the resource

Click Create resource to complete the setup. You can then click either Create app to immediately start building a Retool app or Back to resources to return to the list of resources.

Next steps

Your GraphQL resource is now ready to use. Check out related queries and code documentation to learn how to interact with GraphQL data.

Queries and code quickstart

Fundamental concepts of queries and code.

Resource query tutorial

Hands-on introduction to querying APIs and databases.

Query GraphQL resources

Learn how to query GraphQL resources.