Reference · built on requestConnectorWork & ticket management

Trello

Boards, lists, cards, checklists, and actions from Trello Workspaces through the Trello REST API and webhooks.

Request accessPricing ↗

About

Trello is Atlassian's board tool. A Workspace holds boards, a board holds lists, and cards move between lists as work progresses. A card carries members, labels, due dates, checklists, attachments, comments, and Custom Field items, and every change is logged as an action. The API is served from https://api.trello.com/1/ and accepts singular or plural nouns in a route.

Through Fibric, an operator watches a board webhook, reads the card and its recent actions, and proposes a list move, a due date, or a comment for your approval. Each approved change leaves a note of what changed, why, and how to put it back.

This is a reference listing. It documents what Fibric would read from Trello and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Boards a member can see through GET /1/members/me/boards, and one board through GET /1/boards/{idBoard}
  • Cards in a list through GET /1/lists/{idList}/cards, with fields chosen by the fields parameter
  • Actions on a board or card, paged with before and since, up to 1000 per query
  • Custom Field items on a card through GET /cards/{id}/customFieldItems
  • Checklists, labels, members, and attachments as nested resources of a card
  • Webhook callbacks carrying the action and the model for a board, card, list, member, or Workspace named by idModel

Proposed actions

  • Target capability: propose a card move or field change through PUT /cards/{id}, including idList, due, dueComplete, idMembers, and idLabels
  • Target capability: propose a comment through POST /cards/{id}/actions/comments
  • Target capability: propose a Custom Field value through PUT /cards/{idCard}/customField/{idCustomField}/item
  • Target capability: propose a new card through POST /cards with a required idList

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Follow up on cards that stall

    Cards in a doing list with no actions for a set period get a proposed comment naming the member and a suggested due date, listed for your approval.

    With Action Follow-up

  • Run onboarding from a template board

    Each new starter gets a board copy. The operator reads checklist completion, flags overdue items, and proposes moving finished cards to done.

    With Onboarding Checklist

  • Sequence the cleaning board

    Room cards move across lists as housekeeping progresses. The operator proposes the next list move when a dependent card completes and comments on the reason.

    With Clean Sequence

  • Log lost and found

    Found items become cards with a location Custom Field. The operator proposes matching a guest inquiry to a card and drafts the reply.

    With Lost and Found

Requirements

  • A Trello Workspace and a Power-Up in the admin portal at https://trello.com/apps/admin to generate the API key
  • A token for a member who can see the boards the operator reads; key and token travel as query parameters or in an OAuth header
  • A callback URL that returns 200 to an HTTP HEAD request when the webhook is created, reachable on port 443
Authentication
An API key from the Power-Up admin portal plus a user token granted at https://trello.com/1/authorize with read, write, or account scope and a chosen expiration.

Limits

  • Each API key allows 300 requests per 10 seconds and each token 100 per 10 seconds; /1/members adds 100 per 900 seconds
  • Action queries return at most 1000 results, and oversized responses are refused with a message to narrow the request
  • Webhooks retry 3 times, after 30, 60, and 120 seconds, and Trello disables a webhook that keeps failing for 30 days
  • More than 200 rate limit errors from one key in a 10 second window return 429 for every remaining request in that window

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Trello ↗

Questions and answers

How does the connector check a webhook callback?
Trello sends an X-Trello-Webhook header: a base64 digest of an HMAC-SHA1 over the request body plus the callbackURL, signed with the app secret. Callbacks come from 104.192.142.240/28 over port 443. The connector recomputes the digest and drops a mismatch.
What can a webhook watch?
Any model that actions apply to, set by idModel: a board, a card, a list, a member, a Workspace, or an enterprise. Each callback carries the action that fired it and the current model. Webhooks are created under /1/tokens/{APIToken}/webhooks/ or /1/webhooks.
How does a user authorize access?
Through https://trello.com/1/authorize with your key, a scope of read, write, or account, an expiration of 1hour, 1day, 30days, or never, and response_type=token. A basic OAuth 1.0 flow also exists. Tokens are revoked from account settings or by DELETE on /1/tokens.
Ask about Trello

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Trello through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy