Rate this page:
This changelog is the source of truth for all changes to the Trello developer platform.
In addition to the action and the model fields, webhook event responses now contain the webhook field, which contains the webhook model itself. The webhook model fields are id, active, callbackURL, description, idModel, consecutiveFailures, firstConsecutiveFailDate.
See our webhook documentation for full details on webhook event responses.
For apps using legacy app keys (app keys created via trello.com/app-key) you can now specify the app author by passing the author query parameter in your OAuth request URL or by setting the appAuthor config option when calling either TrelloPowerUp.initialize or TrelloPowerUp.iframe, depending on your workflow.
Please update each and every one of your apps using Trello OAuth with legacy app keys to include your app’s author name, otherwise you risk your app falling out of compliance and potentially getting it delisted from Trello.
For more info please refer to the documentation of the OAuth method you’re using:
- t.authorize()
- t.getRestApi().authorize()
We currently disable webhooks when they “fail” consecutively for 30 days without recovering. Previously, the only type of “failure” was when the webhook callback endpoint returned something other than a 200 response when a webhook event was sent. With this change, webhook events failing because its token lost access to the webhook's model is now considered a failure, and will count towards disablement if not fixed within 30 days.
How does a webhook’s token lose access to the webhook’s model? The most common way this can happen is by a user leaving a board. See this example:
A webhook is set up using a user’s token to watch a board they are a member of.
Later on, that user leaves the board. Thus, their token loses access to the board.
Now, if changes are made on the board, the webhook watching that board will throw an error when attempting to send the webhook event to the webhook’s callback endpoint. This is because the webhook’s token can’t access the model (the board).
If the webhook’s token doesn’t regain access to the model (that is, the user never re-joins the board), the webhook will be disabled after 30 days.
Note that before this change, webhook tokens losing access to the webhook's model already caused webhook events sending to fail. This change simply considers this a “consecutive failure” and will contribute to eventual disablement of the webhook.
API responses for custom field items will now include value and idValue fields with a null value, rather than omitting the fields depending on the custom field type, to maintain consistent API response shapes.
GET /1/card/:id/customFieldItems
Before:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[
{
"id": "64638429a6afeadf0d5795f6",
"idCustomField": "615dca8087f377004a347073",
"idModel": "646383ecbaea32cb431a606d",
"idValue": "615dca902bfde800dec91fb1",
"modelType": "card"
},
{
"id": "6463842b5617d811b4250a9f",
"idCustomField": "615dca66da745f00356d1246",
"idModel": "646383ecbaea32cb431a606d",
"modelType": "card",
"value": { "text": "Test" }
}
]After:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[
{
"id": "64638429a6afeadf0d5795f6",
"idCustomField": "615dca8087f377004a347073",
"idModel": "646383ecbaea32cb431a606d",
"idValue": "615dca902bfde800dec91fb1",
"modelType": "card",
"value": null
},
{
"id": "6463842b5617d811b4250a9f",
"idCustomField": "615dca66da745f00356d1246",
"idModel": "646383ecbaea32cb431a606d",
"idValue": null,
"modelType": "card",
"value": { "text": "Test" }
}
]Workspaces that own publicly listed Power-Ups can no longer be deleted. This will prevent those Power-Ups from breaking for other users that have them installed. Users need to remove all publicly listed Power-Ups from a workspace before deleting it.
When making a DELETE call, we will now check for public power-ups with a matching idOrganizationOwner. If any exist, we will return a 400 error code with the message Workspaces with publicly power-ups can't be deleted (translated into various languages).
We're happy to announce that authorized users can now manage storage for disabled Power-Ups. When an authorized user disables a Power-Up from Trello board(s), they may choose to clear the board-level storage as a part of that action. This action clears all public Power-Up data on the board.
This action is available to users with board administration, workspace administration, or ENT administration privileges. It is not currently available to administrators that choose to “bulk disable” a Power-Up from all boards in a workspace.
What do you need to do?
If you provide documentation or guidance to users about the retention of Power-Up data after the Power-Up is disabled, you should update it accordingly.
For Trello enterprises that have opted in to user management via Atlassian Admin, some Enterprise API endpoints will function slightly differently.
GET /enterprises/{id}/auditlog will contain actions taken in Atlassian Admin, but may not contain the source for those actions.
PUT /enterprises/{id}/organizations will result in the organization being added to the enterprise asynchronously. A 200 response only indicates receipt of the request, it does not indicate successful addition to the enterprise.
PUT /enterprises/{id}/members/{idMember}/licensed Revoking of licenses is no longer possible.
PUT /enterprises/{id}/members/{idMember}/deactivated Deactivation is no longer possible.
PUT /enterprises/{id}/admins/{idMember} is no longer available.
DELETE /enterprises/{id}/admins/{idMember} is no longer available.
GET /enterprises/{id}/organizations/bulk/{idOrganizations} will result in organizations being added to the enterprise asynchronously. A 200 response only indicates receipt of the request, it does not indicate successful addition to the enterprise.
Previously, attempting to add a deactivated workspace member to a board returned a 200 response code, even though the member wasn't actually added. Now, attempting to do so will correctly return a 403 Forbidden error with the accompanying message, "Must reactivate user first.”
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.
For more information on t.card(), see Accessing Trello Data.
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.
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.
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.
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.
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,
1
https://trello.com/1/cards/{id}/actions?display=true&filter=addAttachmentToCard,addChecklistToCard,addMemberToBoard,addMemberToCard,addToOrganizationBoard,commentCard,convertToCardFromCheckItem,copyBoard,copyCard,copyCommentCard,createBoard,createCard,createCustomField,createList,declinedInvitationToBoard,declinedInvitationToOrganization,deleteAttachmentFromCard,deleteCard,deleteCustomField,emailCard,makeAdminOfBoard,moveCardFromBoard,moveCardToBoard,removeAdminFromBoard,removeChecklistFromCard,removeFromOrganizationBoard,removeMemberFromCard,unconfirmedBoardInvitation,updateBoard,updateCard:closed,updateCard:due,updateCard:dueComplete,updateCard:idList,updateCard:name,updateCheckItemStateOnCard,updateCustomField,updateList:closed,updateList:name&limit=50&reactionsSummary=trueThe 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=trueFrom 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.
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.
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.
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.
Invalid parameters, like invalid scopes or invalid expiration continue to return 400.
App not found error, where the app key is incorrect, now returns 404 (Not Found).
Enterprise related application consent restriction errors now return a 403 (Forbidden).
Member not authenticated error from the token/approve route now returns 401 (Unauthorized).