Authentication overview

Trello's API enables programmatic interaction with boards, cards, and other organizational components. To ensure secure access and protect user data, all requests to the Trello REST API must be authenticated. Trello supports two primary authentication methods: using a combination of an API Key and a User Token, or employing OAuth 1.0a for more complex, user-facing applications. The choice of method depends on the integration's scope and security requirements, ranging from simple scripts to full-fledged applications requiring user consent for data access.

The Trello API adheres to standard web security practices, including rate limiting to prevent abuse and ensuring that sensitive user data is only accessible with explicit authorization. Understanding the nuances of each authentication method is crucial for developing secure and functional integrations with Trello.

Supported authentication methods

Trello offers distinct authentication mechanisms tailored to different integration scenarios, each with specific use cases and security implications. Developers must select the appropriate method based on whether they are building a personal script, an internal tool, or a public-facing application.

Method When to Use Security Level
API Key & User Token Personal scripts, internal tools, server-side applications where the user token can be securely stored. Suitable for integrations that act on behalf of a single, known user. Moderate (requires secure storage of the user token; direct exposure can lead to unauthorized access).
OAuth 1.0a Third-party applications, public integrations, or any scenario where your application needs to access Trello data on behalf of multiple users without storing their Trello passwords. Requires user consent. High (tokens are short-lived, user-specific, and revocable; application never sees user credentials). OAuth is an open standard for delegated authorization, as detailed by the OAuth 1.0 Protocol.

The API Key identifies your application, while the User Token (or OAuth Access Token) identifies the specific Trello user on whose behalf the request is being made. Both are essential for successful authentication.

Getting your credentials

Accessing the Trello API requires obtaining specific credentials, which vary depending on your chosen authentication method.

For API Key and User Token:

  1. Obtain your API Key: Navigate to the Trello Developer API Keys page. Your API Key will be displayed there. Keep this key confidential.
  2. Generate a User Token: On the same Trello Developer API Keys page, under the 'Your Token' section, click the link to 'Manually generate a Token'. This will redirect you to an authorization page where you grant your application (identified by your API key) permission to act on your behalf. After granting permission, your User Token will be displayed. This token is specific to your Trello user account and represents your authorization.

Important: User Tokens have an expiration period. By default, they expire in 30 days. You can choose to generate tokens with a longer expiration (e.g., 1 hour, 1 day, 30 days, or never) during the generation process, which is useful for long-running server-side applications. Always store these credentials securely.

For OAuth 1.0a:

OAuth 1.0a is a more involved process designed for third-party applications that need to interact with multiple users' Trello accounts. The general flow involves:

  1. Register your application: While Trello's specific developer console for OAuth application registration isn't publicly linked as a single page, the process is detailed in the Trello REST API Authorization guide. This typically involves providing an application name, description, and callback URL.
  2. Obtain Request Tokens: Your application initiates the OAuth flow by making a request to Trello's API to get a temporary 'Request Token'.
  3. Redirect User for Authorization: You redirect the Trello user to Trello's authorization page, passing the Request Token. The user reviews the permissions your application is requesting and grants access.
  4. Receive Verifier and Exchange for Access Token: Trello redirects the user back to your specified callback URL with a verifier code. Your application then uses this verifier code, along with the Request Token, to exchange them for a permanent 'Access Token' and 'Access Token Secret'.

The Access Token and Access Token Secret are what your application will use for all subsequent authenticated requests on behalf of that specific user. The Trello REST API Authorization documentation provides a detailed step-by-step guide for implementing OAuth 1.0a.

Authenticated request example

Once you have your credentials, you can make authenticated requests to the Trello API. The following example demonstrates how to fetch a user's boards using an API Key and User Token. For OAuth, the process involves signing the request with the consumer secret and access token secret, which is typically handled by an OAuth library.

Using API Key and User Token (cURL example):

This example retrieves all boards for the authenticated user. Replace YOUR_API_KEY and YOUR_USER_TOKEN with your actual credentials.


curl "https://api.trello.com/1/members/me/boards?key=YOUR_API_KEY&token=YOUR_USER_TOKEN"

In this example, members/me/boards refers to the endpoint for retrieving the boards of the currently authenticated user. The key and token parameters are appended directly to the URL as query parameters. For security reasons, sensitive credentials like tokens should ideally be passed in the HTTP Authorization header or handled by secure client-side storage mechanisms, especially in production environments.

Using OAuth 1.0a (Conceptual example):

With OAuth, requests are signed using a combination of consumer key, consumer secret, access token, and access token secret. Libraries in various programming languages (e.g., Python's requests-oauthlib, Node.js's oauth-1.0a) handle the complexities of signing requests. The conceptual request would look like:


// Pseudocode for an OAuth request
const oauth = new OAuth({
  consumer: { key: 'CONSUMER_KEY', secret: 'CONSUMER_SECRET' },
  signature_method: 'HMAC-SHA1',
  hash_function: (base_string, key) => crypto.createHmac('sha1', key).update(base_string).digest('base64')
});

const request_data = {
  url: 'https://api.trello.com/1/members/me/boards',
  method: 'GET',
  data: { /* any query params */ }
};

const token = {
  key: 'ACCESS_TOKEN', 
  secret: 'ACCESS_TOKEN_SECRET'
};

const authHeader = oauth.toHeader(oauth.authorize(request_data, token));

fetch(request_data.url, {
  method: request_data.method,
  headers: {
    'Authorization': authHeader.Authorization
  }
});

This illustrates that the authentication details are part of the Authorization header, generated by an OAuth library.

Security best practices

Adhering to security best practices is paramount when integrating with the Trello API to protect user data and maintain the integrity of your application.

  • Keep Credentials Confidential: Never hardcode API keys or user tokens directly into client-side code or public repositories. Use environment variables, secure configuration files, or dedicated secret management services. For server-side applications, ensure these are stored in a secure, encrypted manner.
  • Use OAuth for Third-Party Applications: For applications serving multiple users or requiring delegated access, always implement OAuth 1.0a. This prevents your application from ever handling or storing user passwords and allows users to revoke access at any time without compromising their Trello account. The OAuth 1.0a specification provides the technical foundation for this secure delegation.
  • Limit Token Permissions: When generating user tokens or configuring OAuth permissions, request only the minimum necessary scope of access. For instance, if your application only needs to read boards, do not request write access. This principle of least privilege reduces the impact of a compromised token.
  • Securely Handle Redirect URIs (OAuth): Ensure that your OAuth callback/redirect URIs are registered and strictly controlled. Only allow redirects to trusted, HTTPS-enabled endpoints to prevent authorization code interception.
  • Implement Rate Limit Handling: Trello imposes rate limits (e.g., 300 requests per 10 seconds per API key/token). Implement proper error handling and back-off strategies in your application to gracefully manage these limits and avoid service interruptions or temporary bans.
  • Regularly Rotate Credentials: Periodically rotate API keys and user tokens, especially for long-lived integrations. This minimizes the window of exposure if a credential is ever compromised.
  • Monitor API Usage: Keep an eye on your application's API usage patterns. Unusual spikes or activity could indicate a compromise or misconfiguration.
  • Use HTTPS: All communication with the Trello API should occur over HTTPS to encrypt data in transit and prevent eavesdropping. Trello's API endpoints enforce HTTPS by default.
  • Error Handling: Implement robust error handling for API responses, especially for authentication-related errors (e.g., invalid token, expired token). This helps in diagnosing issues and maintaining application stability.