- 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
- Go to Settings > OAuth Apps in your Teable account.
- Click New OAuth Apps to create a new application.
-
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
- 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: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:
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
Step 3: Handle the Callback
After the user approves (or denies), Teable redirects to your callback URL: On success:Step 4: Exchange Code for Tokens
Exchange the authorization code for access and refresh tokens:
Example Request:
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
Example:
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
PKCE mode does not require
client_secret. The code_verifier is used instead to verify the client’s identity.Using Access Tokens
Include the access token in theAuthorization header for API requests:
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:
Example Request:
Revoking Access
For OAuth App Owners
Revoke the app’s access for all users (only the app creator can do this):For Users
Revoke your own authorization for a specific app: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
- Choose the right mode: Use client secret mode for web apps with a backend, PKCE mode for native apps/CLI/SPA
- Store secrets securely: Never expose your Client Secret in client-side code
- Use state parameter: Always include a random
stateparameter to prevent CSRF attacks - Request minimal scopes: Only request permissions your application actually needs
- Handle token refresh: Implement automatic token refresh before expiration
- Secure token storage: Store access and refresh tokens securely on your server

