Skip to main content
OAuth Apps allow third-party applications to access Teable on behalf of users. This guide explains how to create and configure an OAuth App, implement the OAuth 2.0 authorization flow, and use access tokens to interact with the Teable API. Teable supports two OAuth 2.0 authorization modes:
  • Authorization Code + Client Secret: For web applications with a backend server
  • Authorization Code + PKCE: For native apps, CLI tools, SPAs, and other public clients that cannot securely store a client secret

Creating an OAuth App

  1. Go to Settings > OAuth Apps in your Teable account.
  2. Click New OAuth Apps to create a new application.
  3. Fill in the required information:
    • OAuth App name: A descriptive name for your application
    • Homepage URL: The full URL to your application’s website
    • Callback URL: The URL where users will be redirected after authorization
    • Scopes: The permissions your application needs
  4. After creating the app, generate a Client Secret. Make sure to copy and store it securely - you won’t be able to see it again.
You’ll receive a Client ID and need to generate a Client Secret. Keep these credentials secure and never expose them in client-side code. If using the PKCE flow, a client secret is not required.

Available Scopes

Scopes define what actions your OAuth App can perform. Available scopes are organized by resource type:
Request only the scopes your application actually needs. Users will see the requested permissions during authorization.

OAuth 2.0 Authorization Code Flow

Teable implements the standard OAuth 2.0 Authorization Code flow:

Step 1: Redirect Users to Authorization

Direct users to the authorization endpoint with your application parameters:
Query Parameters: Example:

Step 2: User Authorization

Users will see an authorization page showing:
  • Your application name and logo
  • The requested permissions (scopes)
  • Options to approve or deny access
If the user has previously authorized your app (within 7 days by default), they will be redirected immediately without seeing the authorization page again.

Step 3: Handle the Callback

After the user approves (or denies), Teable redirects to your callback URL: On success:
On denial:

Step 4: Exchange Code for Tokens

Exchange the authorization code for access and refresh tokens:
Request Body: Example Request:
Response:

PKCE Authorization Flow

PKCE (Proof Key for Code Exchange) is designed for applications that cannot securely store a client secret, such as native desktop apps, mobile apps, CLI tools, or single-page applications.

Step 1: Generate PKCE Parameters

Before initiating authorization, the client needs to generate a pair of PKCE parameters:

Step 2: Redirect Users to Authorization

Query Parameters: Example:
In PKCE mode, redirect_uri supports loopback addresses (http://127.0.0.1, http://[::1], http://localhost) with flexible port matching - you don’t need to register each port exactly.

Step 3: Handle the Callback

Same as the standard authorization code flow - after user approval, the authorization code is returned via redirect.

Step 4: Exchange Code + code_verifier for Tokens

Request Body:
PKCE mode does not require client_secret. The code_verifier is used instead to verify the client’s identity.
Example Request:
The response format is the same as the standard authorization code flow.

Using Access Tokens

Include the access token in the Authorization header for API requests:
Typically, the first step after obtaining a token is to retrieve all Bases accessible to the current user:
This endpoint returns all Bases the current user has permission to access. You can use the baseId from the response for subsequent API calls.

Refreshing Access Tokens

When an access token expires, use the refresh token to obtain a new one:
Request Body: Example Request:
After refreshing, the previous refresh token becomes invalid (Refresh Token Rotation). Always store the new refresh token from the response.

Revoking Access

For OAuth App Owners

Revoke the app’s access for all users (only the app creator can do this):
This deletes all users’ authorization records and tokens, completely preventing the app from accessing any user’s data.

For Users

Revoke your own authorization for a specific app:
This only invalidates the current user’s access tokens and refresh tokens, without affecting other users. Users can also revoke access through their Authorized Apps settings page.

For Applications

Applications can revoke their own access using an Access Token:
This endpoint only accepts Access Token authentication, not session authentication.

Token Expiration

Error Handling

Common error responses:

Best Practices

  1. Choose the right mode: Use client secret mode for web apps with a backend, PKCE mode for native apps/CLI/SPA
  2. Store secrets securely: Never expose your Client Secret in client-side code
  3. Use state parameter: Always include a random state parameter to prevent CSRF attacks
  4. Request minimal scopes: Only request permissions your application actually needs
  5. Handle token refresh: Implement automatic token refresh before expiration
  6. Secure token storage: Store access and refresh tokens securely on your server

Complete Examples

Node.js (Authorization Code + Client Secret)

Python (PKCE Mode for CLI Tools)

Last modified on March 5, 2026