Last updated Aug 18, 2022

Rate this page:

Trello Changelog

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

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:

10 December 2020

Announcement Update format-url capability

We've added a more robust unfurling experience for the format-url capability.

The capability now accepts the following options to allow Trello to provide a more robust experience: subtext, thumbnail, and actions.

For example, the Dropbox Power-Up provides a preview thumbnail, information about a links' last edit as subtext, and the option to "Download" as one of its `actions`.

Example Code

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 javascriptwindow.TrelloPowerUp.initialize({ 'format-url': function (t, options) { // options.url has the url that we are being asked to format return { icon: GRAY_ICON, // don't use a colored icon here text: '👉 ' + options.url + ' 👈', subtext: 'This will show us some text.', thumbnail: IMAGE_URL // OK to use colored image here. actions: [{ text: 'Download', callback: () => { // The function to run when the button is clicked. return }, }] }; // if we don't actually have any valuable information about the url // we can let Trello know like so: // throw t.NotHandled(); }});

9 December 2020

Announcement Updated Authenticated Access to S3

tl;dr - Trello will begin requiring API key and token authorization via the Authorization header to access card attachment download URLs.

Update: This was previously announced but the implementation has changed enough that we are re-announcing. Query parameter-based authorization will be turned off on January 25, 2021. The manually built /download/ routes we previously recommended continue to be our recommendation moving forward.

We will be reaching out directly to developers who are using query parameters for authorization to ensure that your applications are updated before query parameter-based auth is turned off.


Authorization for attachments will be turned on for individual enterprises on an enterprise-by-enterprise fashion. We will create a new changelog card at the point in time it is going to be turned on for all attachments.As of right now, you can construct the future-proof `/download/` URLs and pass in an Authorization header. We *HIGHLY* recommend updating to use this access pattern now as no changes will be required when authorization is required. More on this in `Opt In To Try New Routes` below.The previously announced query-based authorization will be turned off on January 25, 2021.## DetailsCurrently, when you make a request to GET a file attachment on a card, you will receive back a payload that includes the URL at which the file is hosted.For instance, with the following request:


You'd get back a HTTP 200 response with the following body:

[{ "id": "5ef22a288dcee602857a9990", "url": ""}]

The URL provided in url is publicly available and requires no authorization of any sort to access.

Moving forward, public access to these files will be turned off. And the value returned for the url will no longer be the location where the file is hosted. Instead it will be a URL that includes /download/ in the path, similar to below:

[{ "id": "5ef22a288dcee602857a9990", "url": ""}]

The /download/ URL format is the following:{idCard}/attachments/{idAttachment}/download/{attachmentFileName}

If you are using the files directly in your application as a single user, you can add in an API key and token to the request to the /download/ URL.

Making a GET request with the key and token in the Authorization header will return the hosted file.For instance, here is how you'd make the request with curl for an attachment with the ID 5edfd184387b678655b58348 and the attachment file named my_image.png:

curl -H "Authorization: OAuth oauth_consumer_key=\"{{key\", oauth_token=\"token\""

If your application needs to give broader access to the file (like showing the file to multiple users), you do not want to leak the key and token. Instead, your client should download a local copy of the file and then manage access appropriately.

Opt In To Try New Routes

You can currently construct the /download/ routes and pass in authorization. We HIGHLY recommend updating to use this access pattern now as no changes will be required when authorization is required.

When constructing the new routes, remember that the name property is user modifiable and may change. For use as a file path either use the new fileName property, or parse the file name out of the url.

8 September 2020

Added Power-Up Admin Collaborators & Creation Permissions Update

Until now, Power-Ups could only be created and managed by admins of the team that owns the Power-Up. That meant that if someone from your marketing team wanted to update the Power-Up's listing, they would have to be an admin of the team or they'd have to bother an admin to make the changes for them.

Now Power-Ups can be created for a Trello team by any member of the Trello team. By default, the user creating the Power-Up and any team admins will have permissions to manage the Power-Up.

Additionally, you can add Trello members from your team to be collaborators on a Power-Up. From the new Collaborators section in the left navigation, you can search for team members and add them as collaborators on the Power-Up.

Collaborators have all the same permissions on the Power-Up as a team admin; they can update listings, turn off/on capabilities, etc. The only thing they can't do is remove team admins.