Last updated May 6, 2022

Rate this page:

Trello Changelog

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

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.

(a)

(b)

16 December 2021

Announcement New Power-Up menu in Trello header

What is changing?

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.

Why is it changing?

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.

What do I need to do?

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 Date:

Target Go Live - January 24th, 2022

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.

Screenshots:

4 November 2021

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

https://community.developer.atlassian.com/t/pure-wildcard-allowed-origins-on-app-keys-will-no-longer-be-recognized-and-will-be-fully-deprecated/52093

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 trello.com/app-key:

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 `trello.com/app-key`
3. Scroll to the Allowed Origin section and delete your wildcard origin.

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

For information about app key allowed origins, please see our documentation: https://developer.atlassian.com/cloud/trello/guides/rest-api/authorization/#allowed-origins

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: 54.156.199.20.

Additionally, we are deprecating 54.164.77.56.

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 107.23.104.115 107.23.149.70 54.152.166.250 54.156.199.20 54.209.149.230 18.234.32.224/28

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: https://developer.atlassian.com/cloud/trello/power-ups/capabilities/card-back-section/

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.

Timeline

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:

curl https://api.trello.com/1/cards/{idCard}/attachments/?fields=url&key=apiKey&token=apiToken}}

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

[{ "id": "5ef22a288dcee602857a9990", "url": "https://trello-attachments.s3.amazonaws.com/5b6893f01cb3228998cf629e/5b6b3ed249cf2381d501427c/c017c7020704c12468c868be104e4ed4/me.png"}]

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": "https://api.trello.com/1/cards/5edfa37673e537161016361c/attachments/5ef22a288dcee602857a9990/download/Screen_Shot_2020-06-23_at_11.13.18_AM.png?signature=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1OTM0NTcyMDAsImV4cCI6MTU5MzQ2MjYwMCwicmVzIjoiNWVkZmEzNzY3M2U1MzcxNjEwMTYzNjFjOjVlZjIyYTI4OGRjZWU2MDI4NTdhOTk5MCIsImlhdCI6MTU5MzQ1OTkwNSwiYXVkIjoiVHJlbGxvIiwiaXNzIjoiVHJlbGxvIn0.8YcOCOFZ4rURYWoiYYEhAEeyQJyMcnSBRo83UviTA_k"}]

The /download/ URL format is the following:

https://api.trello.com/1/cards/{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\"" https://api.trello.com/1/cards/5e839f3696a55979a932b3ad/attachments/5edfd184387b678655b58348/download/my_image.png


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.

7 August 2020

Announcement Authenticated Access to S3

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

Timeline

As of right now, you can construct the future-proof /download/ URLs and pass in authorization. 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.

We are working to determine the date at which we will limit all authorization validity to 1 hour permanently.

Details

Currently, 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:

curl https://api.trello.com/1/cards/{idCard}/attachments/?fields=url&key={{apiKey}}&token={{apiToken}}

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

1 2 3 4 [{ "id": "5ef22a288dcee602857a9990", "url": "https://trello-attachments.s3.amazonaws.com/5b6893f01cb3228998cf629e/5b6b3ed249cf2381d501427c/c017c7020704c12468c868be104e4ed4/me.png" }]

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:

1 2 3 4 [{ "id": "5ef22a288dcee602857a9990", "url": "https://api.trello.com/1/cards/5edfa37673e537161016361c/attachments/5ef22a288dcee602857a9990/download/Screen_Shot_2020-06-23_at_11.13.18_AM.png?signature=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1OTM0NTcyMDAsImV4cCI6MTU5MzQ2MjYwMCwicmVzIjoiNWVkZmEzNzY3M2U1MzcxNjEwMTYzNjFjOjVlZjIyYTI4OGRjZWU2MDI4NTdhOTk5MCIsImlhdCI6MTU5MzQ1OTkwNSwiYXVkIjoiVHJlbGxvIiwiaXNzIjoiVHJlbGxvIn0.8YcOCOFZ4rURYWoiYYEhAEeyQJyMcnSBRo83UviTA_k" }]

The /download/ URL format is the following:

https://api.trello.com/1/cards/{idCard}/attachments/{idAttachment}/download/{attachmentFileName}

The url value returned from the API includes a signature parameter which is valid for 1 hour with the /download/ URL. If you were to make a GET request to the URL without the signature (or after it has expired) you would receive a 401.

Moving forward, there are two options for accessing the file for extended amounts of time.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 will return a 302 that redirects to the URL of the hosted file. You will always be 302'ed so long as the tokened user has access to the attachment. The route you are redirected to is only valid for 1 hour.

If your application exposes the URL to users other than the one who has granted your application access, you should not use this method.


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, and so you should use the following method of making a preflight HEAD request.

Making a HEAD request to the /download/ URL with a valid key and token results in a 302 HTTP response with a Location: header that is the URL of the file.

For instance, here is the HEAD request:

curl --head https://api.trello.com/1/cards/{idCard}/attachments/{idAttachment}/download/Screen_Shot_2020-06-23_at_11.13.18_AM.png?signature\={signatureFromAbove}\&token={token}\&key={key}

And our response with the Location: header:

HTTP/1.1 302 Found[...]Location: https://trello-attachments.s3.amazonaws.com/5edfa37573e53716101635c9/5edfa37673e537161016361c/1fe80390ba5fe13ef04f612c51647f7c/Screen_Shot_2020-06-23_at_11.13.18_AM.png[...]

The URL in the Location header is accessible for 1 hour. Your application can safely share that URL for the duration of its validity.

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.

29 July 2020

Added New save-attachment capability

If your Power-Up connects to a file storage platform, you can use this capability to show users that native attachments on Trello cards can be saved to your platform for better collaboration.

For instance, the Dropbox Power-Up allows users to save the attachment to their Dropbox account:

Example Code

1 2 3 4 5 6 7 8 9 javascriptwindow.TrelloPowerUp.initialize({ 'save-attachment': function(t, options){ return { callback: function (t, opts) { // code to save the attachment to the platform // information about the attachment can be found at options or opts } } }});

20 July 2020

Announcement New Aux API Request Errors

Some API requests require additional, sub-requests to be made by the Trello server. Each auxiliary API request performed behind-the-scenes of an actual API request has the potential to throw an error.

Previously, the sub-request would bubble its failure up to the top level and return a 4XX. This could make it hard to identify the underlying cause of the error.

With this change, when a subrequest errors, instead of passing that error up to the main request, Trello will throw a new SubrequestFailed error, attach some identifying information about the original error and what path it occurred on, and pass that SubrequestFailed error up to the main request. This error will have a status code of 449.

If your integration catches specific status codes, it should add a handler for the 449 status code. This new error can occur any place where a 4XX error was previously occurring.

For instance, previously we may have returned the following error when a subrequest failed:

1 HTTP 401 Body (text): unauthorized permission requested

And now we would return:

HTTP 449
Body (JSON): { path: 'boards', originalMessage: 'Unauthorized', originalStatus: 401 }

29 May 2020

Announcement Add allow-downloads to iframe sandbox attributes

Google Chrome 83 began to disallow iframes from downloading unless the allow-downloads key is added to an iframe's sandbox attributes: https://www.chromestatus.com/feature/5706745674465280As some Power-Ups would like to be able to trigger downloads upon user action, we have added the `allow-downloads` to the list of attributes.With this change, the attributes currently included are: > allow-scripts allow-forms allow-popups allow-same-origin allow-popups-to-escape-sandbox allow-modals allow-presentation allow-storage-access-by-user-activation