Getting 204 (no content) while attaching tag to a sticky note

Hi @Nikhil Sachdeva, 

Did you create the tag(s) before attaching them?

Have you tried refreshing the board after attaching them? 

Hey Anthony,

Yes the sticky note item and tag exist with their respective IDs, that I get via their get APIs. I’ve tried this on multiple Miro boards, with correct IDs and seem to give 204 every time. When I mention wrong IDs, it does throw an error.

@Anthony Roux I am also running into a variant of this issue.

Though I am able to attach tags to items via the API, there were 2 major unexpected quirks:

1. The tags are not reflected in the Miro board until after I refresh the page for an open Miro board in an active browser tab, unlike other items which reflect realtime updates after API-driven changes.
2. As @Nikhil Sachdeva already pointed out, the API endpoint erroneously returns a 204 response instead of the expected documented 200 response, and the API response has no response body contents.

FWIW, in my case this was using the API reference request playground feature to test out the “Attach tag to item” endpoint, but I did so with a V1 Miro App’s auth bearer credentials.

Is there some strange possibility that the tags API may only work with V1-scoped app credentials and doesn’t work at all with dev V2 API credentials, even though this is a V2-only endpoint/feature?

I was actually a bit surprised it worked at all with my V1 credentials, albeit with the 2 quirks outlined above.

Thanks @Ethan Sherbondy for sharing this.

I was testing it myself and I can confirm your point 1 and 2.

1. This is a limitation we have with this REST API endpoint, the UI doesn’t automatically refresh to show the tag. This come from a larger technical issues and I am not sure when we will be able to fully fix it.
2. This is a clear documentation issue, I raised it internally and it should be fixed soon. 

Regarding your question, there is no difference between an access token for v1 or v2 (for REST). The auth process is the same. It is different for SDK v1 and SDK v2 apps (that needs to be configured at the app settings level).

Thanks for the quick follow-up and clarification.

One more theory / question around why the attach tag to item API seems to not work sometimes, I am curious about if and when Miro unique identifiers need to be escaped, and whether this may have any impact on the API request.

Eg I’ve noticed that board IDs can contain special characters like equal signs (eg = becomes %3D) which often need to be escaped in URLs in order to not get mixed up with query params during URL parsing.

Is it possible that there are edge cases around unique identifier escaping that may affect the endpoint?

Does Miro have some reference documentation that covers if/when/how to urlencode/escape special characters that occur in unique identifiers for API request URLs? Or is it pretty permissive about these?

Also, any guarantees around special characters *not* occurring in other IDs for things like items / tags? Will those always be numeric strings?

@Anthony Roux FWIW do believe the intermittent issue has to do with using unescaped board IDs.

Think it’d be an amazing addition to the API reference / supporting docs to clearly spell out the requirements for urlescaping unique IDs in Miro.

It seems like different entities across the product have different unique ID string formats, and there are different levels of permissiveness when it comes to the API allowing escaped vs. unescaped IDs.

It’d be great to have some canonical reference around best practices when it comes to url escaping/encoding unique IDs, especially given there are so many different unique ID formats within Miro.

It is a bit strange to me (if this theory is accurate) that eg the API happily returns a success response when using an unescaped board ID but yields a noop, rather than throwing an error or otherwise loudly indicating to the dev that the request may actually be malformed.

Not that I am aware of, we haven’t experienced this (and most of board id have special characters). If you experience something different, please let me know.

When you say “seems to not work sometimes”: have you experienced issues other than the 2 you raised above? I am not aware of any other issues related to tags. Same as above, if you face any of this issue, please raise them so the team can investigate.

Thanks, really appreciate your time helping us to fix and improve the platform!

This is still not documented. Still not fixed. Experiencing the same issue.

Hey @Yachal Upson,

Sorry to hear that you’re having issues with this. To confirm, are you receiving an error when attempting to hit the Attach Tag endpoint? Or are you specifically having an issue with only certain requests/specific board IDs?

Thanks!
Will

@Will Bishop 
Hey Will,

As per the the topic it’s two parts, and endpoint specific.

1. The 204 response is consistently generated when we hit the Attach Tag endpoint from a python script or via the Miro ‘ReadMe’ docs platform. Not a show stopper, but still occurring.
2. Board (tag) updates via the API still aren’t visible unless we exit the board and open it again. This is a real frustration.

Hi @Yachal Upson,

Thanks for clarifying! 

You’re correct—these are 2 currently known limitations of this endpoint. Our documentation reflects the 204 response as the expected response at this time, though we appreciate the feedback. We’ve raised this with our team internally.

As for the tag updates via API, we’re aware of this and are hoping to address it in the future. Unfortunately we don’t have an ETA for this, but I can understand there’s room for improvement here and will continue to advocate for enhancing this so updates don’t require a board refresh.

Thanks again for raising these to us,
Will