Hi all — we run Voiact (https://voiact.com), an AI assistant that drives Trello over natural language, so we hit a lot of the REST API surface. We ran into a visibility inconsistency around archived LISTS and wanted to flag it / ask whether it’s intended.
SUMMARY
Archiving a LIST does not change the “closed” state of the cards inside it — the cards keep closed:false. As a result, GET /1/boards/{id}/cards?filter=open and GET /1/members/me/cards?filter=open still return those cards, even though they are hidden in the Trello web UI and excluded from the Search index.
There is no card filter that reflects “visible on the board” (card open AND parent list open), so every consumer has to cross-reference list state manually to match what the user actually sees.
REPRODUCTION (verified against a live board)
1. Create a list: POST /1/lists?name=Demo&idBoard={board} → list L
2. Create a card in it: POST /1/cards?name=Demo&idList={L} → card C (closed:false)
3. Archive the LIST (not the card): PUT /1/lists/{L}/closed?value=true → list L closed:true; card C untouched
4. The card itself is still open: GET /1/cards/{C}?fields=closed,idList → closed:false
5. Board cards, open filter: GET /1/boards/{board}/cards?filter=open → C IS returned (!)
6. My cards, open filter (if assigned): GET /1/members/me/cards?filter=open → C IS returned (!)
7. Search: GET /1/search?query=Demo&card_list=true → C returned, but card.list.closed:true is exposed
8. Trello web UI → C is HIDDEN
THE INCONSISTENCY
Three endpoints behave differently regarding the parent list’s archive state:
- /1/search (card_list=true): returns the archived-list card AND exposes card.list.closed — so a client CAN detect the archived list here.
- /1/boards/{id}/cards: returns the archived-list card but only gives idList — the client needs a separate /lists call to learn the list is archived.
- /1/members/me/cards: returns the archived-list card and ignores the list=true nested param entirely (no list object in the response at all) — so the client CANNOT detect list state from this endpoint. This looks like a separate minor issue on its own.
So Search already exposes enough to filter correctly, but the two card-collection endpoints don’t.
WHAT WOULD HELP (any one of these)
1. Docs: a note in the cards “filter” docs clarifying that filter reflects card-level archive only, not the parent list’s state.
2. Consistency: surface list.closed on /boards/{id}/cards and honour list=true on /members/me/cards, so clients can match UI/Search visibility without an extra round-trip.
3. Nice to have: an optional filter such as cardListFilter=open to return only cards whose list is also open.
Happy to share board IDs or a HAR capture if useful. Thanks!