IDs inconsistent across REST API endpoints

  • 5 April 2022
  • 9 replies
  • 139 views

Badge +1

Problem

  1. Call https://developers.miro.com/reference/get-logs → the https://developers.miro.com/reference/log-object yields a board ID like 3074457347733873980
  2. Calling https://developers.miro.com/reference/get-board with that ID fails. Here we need to use the short ID o9J_ktAiH3s=

Possible solutions

  1. Make get-board accept long form of the id
  2. publish shortening algorithm / API

9 replies

Userlevel 5
Badge +1

Thanks @Matthias.Cullmann for raising this. 

 

I raise this to the API team and will come back to you when I have more information.

Badge +1

Thanks @Anthony Roux , any news yet?

Badge +1

Hello @Anthony Roux , sorry for annoying you. For my expectation management: is this going to take hours, days, weeks or months?

Userlevel 5
Badge +1

Hi @Matthias.Cullmann,

 

The feedback has been raised to the Enterprise team. This will have to be prioritize among other requirements. It is for the moment part of our backlog without an ETA. In all transparency this is most probably be prioritized by the development teams in a couple of weeks. 

Badge +1

Hi @Anthony Roux ,

coming back on this. A few couples of weeks have passed. Any updates? Do you have a ETA?

Best regards,

Matthias

Userlevel 6
Badge +4

Hi @Matthias.Cullmann,

Thanks for following up on this, and apologies for the delay in getting back to you with an update. I can certainly appreciate the importance of addressing this to unlock the further use of the board ID returned by our Audit Logs endpoint.

I’ve just checked back in with our Enterprise team, and I can confirm that this feedback is still on our Enterprise team’s radar. While we don’t have a concrete ETA to offer at this exact moment, it does seem likely that this will be addressed, but it’s currently being scoped amongst other competing priorities. 

That said, it’s something we’re pushing for, and we’re optimistic that we should be able to offer a better ETA on it soon. To be fully transparent, this is likely to be prioritized in the coming months, rather than weeks as we had initially hoped.

We will be happy to keep this thread open and share updates as we have them, but wanted to make sure we were able to get back to you in the meantime, even if it’s not the exact update we hoped to have by now. 

Don’t hesitate to let us know if you have further questions or feedback in the meantime.

Best,
Will

Badge +1

Hi @Will Bishop,
I came across a similar problem while trying to use get-logs for an internal app. Is there some workaround which you can share here which can help us map the shorthand board ID (o9J_ktAiH3s= in the example above) to the board ID returned by the getLogs API call (3074457347733873980 in the example). 

 

Userlevel 5
Badge +1

I there might be a workaround but it depends how you ingest Audit Logs.

 

The “board_created” event contains both: the board ID and board key. If you can query the Audit Logs using the board ID (the long number), you will find the Log entry when the Board was created and there you have both data points. 

This is clearly not a scalable solution and a bad developer experience. 

Offering both ids is part of our roadmap but I don’t have an ETA for the moment.

Sorry for the inconvenience. 

Badge +1

Hi @Anthony Roux,

The workaround you suggested would it work if the board was created long ago? I asked a question here, and based on the response it seems that if the board was created before the newest 100k events (or long ago), we would not be able to get the board ID to board key mapping, right?

Reply