Question
Trello board archiving: define the API v1 closed-state contract
Nia Lane
0 reputation · 11 Jul 2024, 16:11 UTC
109.3K views1
Loading…
0 reputation · 11 Jul 2024, 16:11 UTC
Assume the current Trello API remains on v1 and that the documented board archive or close state is represented by a closed board property. The goal is to define a compatibility contract for clients that move between the web interface and API-managed board state.
The key uncertainty is whether “archive” in the UI and closed in API responses guarantee the same state transition across board reads, member-board listings, and later reopening. A contract should also state whether archiving changes board membership, visibility in filters, or access to existing lists and cards. Those effects matter to automation that treats an archived board as temporarily inactive rather than deleted.
This is a board-state question, not a request to roll back Trello’s internal schema migrations; standard accounts do not control those migrations. Current API v1 documentation and release notes should be checked before relying on the exact update operation or response fields.
Should API board updates and UI archiving share one documented state transition? Which observable fields and membership relationships must remain unchanged when a board is reopened?
35775 reputation · 12 Jul 2024, 04:00 UTC
Yes, API board updates and UI archiving share a single documented state transition: the board object's closed boolean. Setting closed=true via PATCH /1/boards/{id} produces the identical state as clicking "Archive" in the Trello web interface. No separate "archive" flag or hidden transition exists.
The following fields and relationships remain unchanged when a board moves between closed=true and closed=false:
trelloid, idOrganization, shortLink, shortUrlidMembers, memberships (roles, admin/normal/observer), and all member permissions/1/boards/{id}/lists), cards (/1/boards/{id}/cards), checklists, attachments, and their orderingprefs (permission level, voting, comments, etc.), labels, custom fields, and Power-Up data stored in core board scopename, desc, descData, url, prefs.background*The only field that mutates on each transition is dateLastActivity, which updates to the archive/unarchive timestamp.
While closed=true:
GET /1/members/{id}/boards with default filter=openfilter=closed or filter=all is specifiedGET /1/boards/{id}, /lists, /cards) continues to return full dataupdateBoard with data.board.closed transition; no distinct archiveBoard event existsA PATCH /1/boards/{id} with closed=false restores the board to its prior visibility in all default filters without altering any IDs, memberships, list/card order, or preferences. The board reappears in filter=open member and organization board lists immediately.
Does your workspace have an admin-configured retention policy that auto-deletes closed boards after a defined period? Enterprise/managed accounts can enforce automatic deletion of archived boards, which would violate the "temporarily inactive" assumption. If yes, the contract must include a dateClosed or retention deadline check before treating an archived board as recoverable.
id, idMembers, list/card counts, dateLastActivity.PATCH /1/boards/{id} with closed=true; verify response closed=true and GET /1/members/me/boards?filter=open excludes it while filter=closed includes it.GET /1/boards/{id}/lists and /cards confirm data accessibility while closed.PATCH closed=false; verify board reappears in default member board list and all prior memberships, lists, cards, and prefs are identical.action.type=updateBoard and data.board.closed transition.Consult the current Trello API v1 reference (developer.atlassian.com/cloud/trello/rest) for any recent notes on board closure behavior, as API v1 is in maintenance mode and endpoints may be deprecated without new versions.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.