Question about POSTing with card covers

Can Cover also be supported for the POST operation pls? Seems to only work for PUT.

1 Like

:wave: A quick housekeeping note: I’ve moved this to a new topic since the original topic is quite a bit old and replies on it alert all of the previous participants.

I’m led to believe the answer is “no” based on a bit of poking around on the Trello web client. Unless I’m missing something, using the Trello web client, you can’t create a card with a cover–you can only add a cover after the card is created.

1 Like

More context on this:

Generally, the API is built to enable some functionality for the first-party Trello clients (mobile/web/desktop). So if I ever want to see whether something is possible, I go and try to make the web client do the thing I want to do and then watch my browser’s network calls to see which APIs it is using.

Thx for the reply. Sorry if my message was unclear. I know that it’s not working :slight_smile: Both my testing and the documentation confirm that.
My question is if can pls be supported in future (i.e. API change request). The Card JSON that the POST and PUT operations accept is identical, except for the Cover attribute, which is missing in the POST. Having to do both a POST and a PUT to specify the Cover of a new card seems a bit weird…


It comes down to interpretations of what POST requests are meant for versus PUT requests, and how Atlassian has chosen to implement that interpretation in the REST APIs for their products. In Trello’s REST API, POST requests are for creating things, and PUT requests are for changing things.

Since a Card needs to created before its cover can be changed, you must initiate a POST request followed by a PUT request, which is totally consistent with all of Trello’s other REST API endpoints.

The distinction between create-parameters and change-parameter is arbitrary (except for mandatory ones), we’ll never get to the end of that.
The resulting behaviour of the way the API is currently implemented is that a new card shows up in the WebUI first default/white, and then - a few moments later - changes to a different color/font (when the cover/PUT comes through). If that is what Atlassian envisages users want, then I rest my case…

1 Like

Well, at least you’re philosophical about it.

Yep, it’s ultimately a ‘where to draw the line’ decision about where to limit the functionality of the POST endpoints. Just enough to get the object to a minimum state without incurring undue backend load and then excessively verbose responses. The rest is optional and can be done via a subsequent change to the object.

The eternal tug-o-war of between performance and convenience :face_with_spiral_eyes: