Last updated Sep 1, 2021

Rate this page:

Trello Changelog

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

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:

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:

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:

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

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:

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:

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

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:

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

30 March 2020

Announcement Update Webhook Server IP Addresses

We are adding new webhook server IP addresses: `18.234.32.224/28` (that is, `18.234.32.224` through `18.234.32.239`). If you manage a list of IPs that you expect Trello webhooks to come from, the list should be updated to include the new IP addresses.All webhook request will come from one of the following IP addresses/subnets:```107.23.104.115107.23.149.7054.152.166.25054.164.77.5654.209.149.23018.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](https://developer.atlassian.com/cloud/trello/guides/rest-api/webhooks/).

17 March 2020

Removed Updating Member Avatar URLs

We've updated the hosting location of Trello users' avatars so that their URI includes the member ID of the user. All of the user's avatars are now nested under their own member ID. Additionally, they are hosted on a new domain.Previously, the `avatarUrl` field on a member looked like this:> https://trello-avatars.s3.amazonaws.com/fc8faaaee46666a4eb8b626c08933e16/170.pngNow, the route looks like this:> https://trello-members.s3.amazonaws.com/5589c3ea49b40cedc28cf70e/fc8faaaee46666a4eb8b626c08933e16/170.png**The REST API is already returning the new route URLs. However, both routes will continue to work until March 31, 2020. **If you are storing `avatarUrl`'s, you should update the data you have stored with the new routes. However, we recommend that you do not store this route and , instead, request it at time of need.Although the `avatarHash` is included in the `avatarUrl`, we do not recommend constructing the avatar URL manually.Calls to `t.member('avatar')` in the Power-Up client library are already using the new URLs and no change is required.

11 March 2020

Added Add t.jwt()

We're adding a new function to the Power-Up client library that allows you to asynchronously request a signed JWT from Trello for the current member.```// a contrived examplewindow.TrelloPowerUp.initialize({ 'board-buttons': async function (t, opts) { if (t.isMemberSignedIn()) { const jwt = await t.jwt({ state: JSON.stringify({ hello: 'world' }), }); console.log(jwt); } return []; }});```If you checked the console you would find a JWT that includes the state you've provided.The purpose of these JWTs is for you to be able to secure the communication between your Power-Up and your server, if needed. If you need to know that a request made by your Power-Up to your server was made on behalf of a particular Trello user, you have two main ways of accomplishing that.If you already need and are retrieving Trello OAuth tokens for members who use your Power-Up, you can send the token in requests to your server, and validate the token by making a request with it to Trello.However, if you don't need a Trello OAuth token (you don't need to talk to Trello's REST API), then you should use this `t.jwt()` method and send the resulting JWT with requests to your server.Trello will provide a public key (https://api.trello.com/1/resource/jwt-public-keys) that can be used to decode the JWT on your server.Read more on how to use this effectively in [`t.jwt()` documentation](https://developer.atlassian.com/cloud/trello/power-ups/client-library/t-jwt/).

10 March 2020

Announcement Allow any URL scheme for Allowed Origins

The [initial allowed origins change](https://trello.com/c/HK7aikI7/59-add-authentication-allowed-origins) disallowed the use of URL schemes other than `http` and `https`; for example, a mobile client wanting to use `my-app://auth-success` as the `return_url` was not able to.We're updating the allowed origins such that any URL scheme is now accepted. However, we will explicitly disallow `javascript:` and `data:` schemes for security reasons.