Developer platform and APIs

Right now, the Miro access tokens are bound to a specific user and a specific team. This requires users to authorize our app multiple times with Miro (for each team). Our users found this pretty counter-intuitive. Their expectations are set by Zoom/Slack/Github which asks users during their default OAuth flow only once to connect the account. It would therefore be easier to if Miro OAuth access tokens could work across teams (and the API requires the team_id as a parameter when e.g. creating a board).  

Today, the api doesn’t allow to set the borderColor to “transparent”. Not setting any value, Miro defaults the border to black. We figured out that setting the borderOpacity to 0 is a possible workaround. Yet, this isn’t ideal because getWidgets doesn’t do this if users create transparent borders in the Miro UI (i.e. input and output API aren’t consistent). It would be great if you would allow API developers to set the border color to transparent.

The API allows to use the following colors for widgets (every other color is rejected): #F5F6F8, #FFF9B1, #F5D128, #D0E17A, #D5F692, #A6CCF5, #67C6C0, #23BFE7, #FF9D48, #EA94BB, #F16C7F, #B384BB Yet, the Miro UI itself supports a different set of colors: #fef445, #fac710, #e6e6e6, #f24726, … This confuses users of API generated widgets because they can’t reproduce the same ones in the UI.  

Regarding the docu (https://developers.miro.com/reference#authorization-and-authentication), the endpoint to trigger the oauth flow is “https://miro.com/oauth/authorize” whereas the code exchange endpoint is “https://api.miro.com/v1/oauth/token”. The API calls itself are as well “https://api.miro.com/v1/boards/id”. This is unexpected and not overly nice when writing integration code. It would be better if you the /authorize endpoint would be consistent => https://api.miro.com/v1/oauth/authorize

The Miro OAuth flows shows a page on which the user can select the team to which Miro should be installed. Afterwards, the code (and subsequently the access_token) is provided. Yet, the flow can be only executed once because the “Installed” button isn’t clickable. This means, in case the application looses the Miro access-token (which I understand from the docu should be cached forever), the user is required to deinstalled the application from Miro and then trigger again the OAuth flow.  

How does the positioning system in the RESTAPI work? What I understood so far is that x/y coordinates define the middle point of the widget and that the values seem to correspond to display pixels. In particular: which x/y coordinates and width/height is advised to use when placing widget (assumption: all team members have different devices)?

Internal hackathons are huge for Miro product culture. We organize them twice a year for two days and last month 20 teams were competing for the main prize for the 7th time in history. I just wanted to share some pictures from this internal event and give a sneak peek into the projects teams were working on.   For example, one of the teams called ‘Dotmocracy’ created a platform app for voting with a predefined amount of dots per user. Other projects include enhanced board history, plugin that allows to automate routine tasks on the board, and even custom Miro Instagram masks and stickers. I’m curious – if you were to participate in Miro Hackathon, what would you build?