Last updated Nov 29, 2022

Rate this page:

Trello Changelog

This changelog is the source of truth for all changes to the Trello developer platform.

29 November 2022

Added Checklists are available via t.card()

You can now include checklists from cards when calling t.card() from the Power-Up Client Library. To do this, pass checklists as a parameter, or use all. For example:

1 t.card('id', 'checklists').then((data) => console.log(data));

The returned information includes the name of the checklist, its position, and an array of the checklist items. This is similar to the results from the Checklists API.

More details

For more information on t.card(), see Accessing Trello Data.

31 October 2022

Announcement New Marketplace Security Requirements Are Now in Effect

Several months ago, we announced new security requirements for cloud apps, which take effect today (October 31). As of today, all Marketplace apps and Trello Apps (Power-Ups) are expected to meet the new requirements.

Maintaining a secure Marketplace is a collective effort, shared by Atlassian and partners. The new requirements reflect the most current best practices for building secure apps and provide platform-specific guidance. They set Atlassian’s baseline standard for cloud app security, and will be updated annually to ensure alignment with industry standards.

The new requirements apply across five categories: Authentication & Authorization, Data Protection, Application Security, Privacy, and Vulnerability Management. They benefit both developers and customers by providing guidelines for building secure apps and elevating the trust posture of our cloud ecosystem.

Read the blog to find out more about the changes that take effect today, and how we will validate that apps are following security requirements moving forward.

Read the blog

27 October 2022

Announcement Trello tokens have gotten longer

We’re increasing the length of Trello tokens. Existing tokens will continue to work, and new tokens will be 12 characters longer.

These changes are planned to be rolled out fully by November 16, 2022.

More details

The tokens are longer because we’re creating a new standard prefix/regex shape for Trello tokens and secrets. This will allow us to automated detection and discovery for leaked tokens.

However, please note that tokens are meant to be “opaque”, meaning their length, shape, or format is not guaranteed. Your application code should not assume anything about the token’s structure. If your application relies on Trello tokens having a specific structure, such as matching a certain regular expression or having a certain character length, you should remove that logic immediately.

But if your app code is already treating Trello tokens as opaque, then you are all set! No action required.

18 August 2022

Added Adding `reactionsSummary` to the `members/me/notifications` route response

The 1/members/me/notifications route now supports a Boolean query parameterreactionsSummary. When the value is true, the response will include a reactionsSummary key that contains the a summary of the user’s reactions.

More details

This change will add functionality that mirrors what is currently available via the /1/cards route’s support of the reactionsSummary query parameter.

For instance, when getting a card,


The last query parameter is `reactionsSummary=true`, and returns the following key and object as part of the JSON response payload:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 "reactionsSummary": [ { "count": 2, "id": "6247578a662f131a4c38df0a:1F631", "firstReacted": "2022-04-01T20:12:11.000Z", "idEmoji": "1F631", "idModel": "6247578a662f131a4c38df0a", "idReaction": "62475d286a49b7b37ba1b3b7", "emoji": { "unified": "1F631", "native": "😱", "name": "FACE SCREAMING IN FEAR", "skinVariation": null, "shortName": "scream" } }, { "count": 1, "id": "6247578a662f131a4c38df0a:1F60D", "firstReacted": "2022-04-01T19:50:39.000Z", "idEmoji": "1F60D", "idModel": "6247578a662f131a4c38df0a", "emoji": { "unified": "1F60D", "native": "😍", "name": "SMILING FACE WITH HEART-SHAPED EYES", "skinVariation": null, "shortName": "heart_eyes" } } ]

With this change, the same query parameter support has been added to the a user’s notifications endpoint:

1 GET /1/members/me/notifications?display=true&filter=cardDueSoon,addedMemberToCard,makeAdminOfBoard,declinedInvitationToBoard,removedFromCard,closeBoard,addedToCard,updateCheckItemStateOnCard,memberJoinedTrello,removedMemberFromCard,addedToBoard,requestAccessBoardWithoutOrganization,commentCard,addAttachmentToCard,makeAdminOfOrganization,changeCard,addedToOrganization,createdCard,mentionedOnCard,removedFromBoard,declinedInvitationToOrganization,removedFromOrganization,requestAccessBoard,requestAccessBoardNotInOrganization&limit=50&reactionsSummary=true

30 June 2022

Fixed Numeric Custom Field Items can no longer be set to empty string via PUT API

From July 11, 2022, you will no longer be able to set the value of a numeric Custom Field item to { number: '' }. It will return a 400 error.

More details

Previously when using a PUT request to update a numeric Custom Field item on a card, you could set the value to { number: '' } (empty string). Doing so would cause the Custom Field item to have this as its value attribute:

1 2 3 { value: { number: '' }, }

This shouldn’t be possible as empty string is not a valid numeric value, and is considered corrupted data. This can also be confused with:

1 { value: null }

which is the correct format of nulled-out Custom Field Item.

This is a bug that arose in January 2022.

Reminder that the correct way to null-out any non-option Custom Field item is to PUT { value: '' } which will cause the item to be nulled out (GET’ing the item afterwards will return { value: null }

For more information on how to use Custom Fields via the API, please see our documentation.

22 June 2022

Added New security requirements for cloud applications

We have updated our security requirements for cloud applications, added new security requirements, and categorized requirements by app type and security requirement type. All cloud applications in the Atlassian Marketplace must adhere to the updated requirements by October 31, 2022.

Please see the blog post and FAQ page accompanying this announcement for more details, as well as this document for specific updates.

16 June 2022

Added New status codes for "/authorize" API route error responses

Previously, any non-200 status code response for the /authorize route was simply a 400. Now, status codes will be different depending on the error.

Please adapt your app code for different status codes if you are handling errors from /authorize.

  1. Invalid parameters, like invalid scopes or invalid expiration continue to return 400.

  2. App not found error, where the app key is incorrect, now returns 404 (Not Found).

  3. Enterprise related application consent restriction errors now return a 403 (Forbidden).

  4. Member not authenticated error from the token/approve route now returns 401 (Unauthorized).

6 May 2022

Fixed Trello now sends webhook action for Trello Cards created with attachment

When you create a Trello card with a file or URL attachment, Trello will now send a separate, additional addAttachmentToCard webhook action after sending the createCard action.

28 March 2022

Added New 3LO App Controls for Site Admins

An improvement will be made in the coming days to allow customers (site admins) to turn off (or back on) end-user installation capabilities for OAuth 2.0 (3LO) apps. If you are a developer of OAuth 2.0 (3LO) apps, you do not need to take any action as a result of this change, as this message is only to communicate the impact to the customer.

More details

Previously, controls were not in place for an admin to block their users from installing 3LO apps. Adding the ability for an admin to prohibit users from installing 3LO apps now aligns more closely to how a user would install any other, non-3LO apps on the Marketplace. This functionality was requested by several Atlassian enterprise customers to gain increased control over where their data is shared and which apps have access to their instance. By allowing admins to control end-user app installs, we are making it possible for more enterprise customers to move to cloud. Once in cloud, these companies will not be blocked from installing 3LO apps, because admins will retain the ability to vet and install the apps at their discretion.

Figure (a) below demonstrates the section of the customer’s admin console where they will now be able to block their users from installing 3LO apps. Figure (b) below shows the new experience when a customer tries to install a 3LO app after their admin has disabled this function.

If a customer attempts to install a 3LO app after their admin has disabled this function, the following error message will appear:

App is blocked by an admin
An admin has not allowed [App Name] to access data from [Your Atlassian Instance] . Select another site to authorize access to or contact your admin for more information.



16 December 2021

Announcement New Power-Up menu in Trello header

We are introducing a new Power-Up menu in the header! This will allow better visibility and management of Power-Ups. This change also includes the ability to show or hide your Power-Up board buttons. In the effort to make the header more focused and streamlined, board buttons will now default to be ‘hidden’ until users enable them to show on the board header.

Edit 1/13/22: In an effort to make the best experience for our development community and customers the default behavior has been changed to display the board buttons by default.

More details

We want to give users more control of a board’s header. The header has had quite a few things added over the development of Trello and this change will allow users more flexibility to see the board how they want.

You may need to update your Power-Up’s user on-boarding and documentation if it includes the use of board buttons. This change will require users to first interact with a board button on the Power-Up menu so any documentation/screen shots will need to be updated. All existing boards that already have Power-Up buttons enabled will have those automatically enabled on the board header.

Target Go Live - January 24th, 2022

4 November 2021

Deprecation Notice Pure wildcard (“*”) allowed origins on app keys will no longer be recognized and will be fully deprecated

Currently, we allow app keys to have pure wildcard allowed origins ("*"). They cannot be added anymore, but if a key had a wildcard origin from before that change was made, the key could continue to use the wildcard origin.

If your key is a legacy app key with a wildcard origin, you should see this message when visiting

On November 4th, we will be fully deprecating wildcard origins, meaning that they will be completely ignored even for legacy app keys. *Apps that depend on wildcard origins to complete their auth flow may no longer work. You must remove the wildcard origin and if appropriate, replace it with a real allowed origin of a service you control*.

To remove a wildcard allowed origin:
1. Login to the account of your api key.
2. Go to ``
3. Scroll to the Allowed Origin section and delete your wildcard origin.

Note that wildcard subdomains are not affected by this change (e.g. `*`).

For information about app key allowed origins, please see our documentation:

1 September 2021

Announcement Custom Fields now required to be specified in keepFromSource when copying a card

When copying a card, you make a POST request to /cards with an idCardSource in the post body. There is also a keepFromSource field, which specifies which special fields should be copied over. Those fields currently are:

1 ['attachments', 'checklists', 'due', 'labels', 'members', 'stickers']

Everything else on the card is copied, including Custom Fields.

Now that Custom Fields is a core feature for paid workspaces, we are adding the option to NOT copy Custom Fields data when copying a card. This means that after this change, in order to copy Custom Fields data when copying a card, you must include "customFields" in keepFromSource.

For example, a POST body copying a card and including Custom Fields:

1 2 3 4 5 6 7 8 { idBoard: "527f5a5219879e23c6cb2908", idCardSource: "610a9f350ed39a812ffe2dae", idList: "604f9ff30f6876e7605b0c50", keepFromSource: ["start", "due", "comments", "customFields"], name: "Card with Custom Fields", pos: "360447" }

23 June 2021

Announcement Deprecating OAuth access to /1/boards/:id/boardPlugins routes

OAuth tokens with the correct scopes have been able to enable and disable Power-Ups on boards via a POST on /1/boards/:id/boardPlugins and a `DELETE on /1/boards/:id/boardPlugins/:idPlugin.

Moving forward, only first party Trello clients will be allowed to use these routes to ensure individual consent is attained prior to changing Power-Ups on a board.

19 January 2021

Announcement Update Webhook Server IP Addresses

We are adding new webhook server IP addresses:

Additionally, we are deprecating

If you manage a list of IPs that you expect Trello webhooks to come from, the list should be updated to include these changes.All webhook request will come from one of the following IP addresses/subnets:

1 2 3 4 5 6

We continue to recommend that you check the x-trello-webhook header included in each webhook request to validate that that the webhook came from Trello's servers. For more on validating signatures, check out the Webhook Signatures section in webhooks' documentation.

11 December 2020

Added Card back sections support an optional action property to add a button at the top right

You can now return an action along with your card-back-section in order to show a button at the top right of your section.

An action consists of two required properties:

  • text - The text to show on the button

  • callback - The function to be called when the user clicks the buttonYour callback can do anything a card-button callback can do, such as opening a t.popup or a t.modal for example.

Check out the full docs for the card-back-section capability for more information: