Skip to main content
Answered

Questions About Image Handling and Query Parameters in Miro API

  • December 2, 2024
  • 2 replies
  • 40 views

Forum|alt.badge.img+4
  • Active Contributor
  • 24 replies

Hey community,

I have a couple of questions regarding image handling in the Miro API:

  1. Differentiating Uploaded vs. Predefined Images
    Is there a way to distinguish between images I’ve uploaded and those predefined on a board template?

  2. Fetching Image Files
    To fetch the actual JPG of an image, I currently have to follow this three-step process:

    • Step 1: Make a request to fetch items and grab the imageUrl.
    • Step 2: Request the imageUrl to obtain another URL.
    • Step 3: Make a final request to the new URL to fetch the JPG.

    The URLs include query parameters like Signature and Key-Pair-Id. What is the purpose of these parameters, and is it possible to use them to group predefined images on boards?

Any help would be greatly appreciated! Thanks!

Best answer by William Bishop

Hey ​@vkoko,

Good questions! Happy to add some color.

First, regarding differentiating uploaded vs. predefined images, there’s not a dedicated param for this, but there are some details you can leverage that might be helpful. For example, if you look at the created_at timestamp for the image, this might be helpful for telling you if the images were created with the board/template initially, or uploaded later. Some other potential workarounds you could leverage:

  1. Consider using the alt text field to store metadata via the REST API to tell you if it’s your own image or another
  1. You could leverage the item-level metadata in our Web SDK, to store an identifier for images of your own

Second, regarding downloading images via REST API, you’re correct. When calling GET items/images, the resource url for the image will be returned within the data object for the item, as imageUrl field. Then you will need to make a GET request to the imageUrl, using the same bearer token used for your original request. It will look something like this:
http://api.miro.com/v2/boards/{boardId}/resources/images/{imageId}?format=original&redirect=false 

Calling this URL will return the download URL. (To download the image directly, we recommend setting format=original and redirect=false. This will return a url to download the original resource directly.)

In terms of the final URL that’s returned, the signature and key-pair-id are not intended to be used programatically be end clients like this, however it’s a great suggestion to enable something like that. I’m happy to pass this feedback along.

I hope it helps to clarify!
Will

View original
Was it helpful?

2 replies

William Bishop
Mironeer
Forum|alt.badge.img+4

Hey ​@vkoko,

Good questions! Happy to add some color.

First, regarding differentiating uploaded vs. predefined images, there’s not a dedicated param for this, but there are some details you can leverage that might be helpful. For example, if you look at the created_at timestamp for the image, this might be helpful for telling you if the images were created with the board/template initially, or uploaded later. Some other potential workarounds you could leverage:

  1. Consider using the alt text field to store metadata via the REST API to tell you if it’s your own image or another
  1. You could leverage the item-level metadata in our Web SDK, to store an identifier for images of your own

Second, regarding downloading images via REST API, you’re correct. When calling GET items/images, the resource url for the image will be returned within the data object for the item, as imageUrl field. Then you will need to make a GET request to the imageUrl, using the same bearer token used for your original request. It will look something like this:
http://api.miro.com/v2/boards/{boardId}/resources/images/{imageId}?format=original&redirect=false 

Calling this URL will return the download URL. (To download the image directly, we recommend setting format=original and redirect=false. This will return a url to download the original resource directly.)

In terms of the final URL that’s returned, the signature and key-pair-id are not intended to be used programatically be end clients like this, however it’s a great suggestion to enable something like that. I’m happy to pass this feedback along.

I hope it helps to clarify!
Will


Forum|alt.badge.img+4
  • Author
  • Active Contributor
  • 24 replies
  • December 3, 2024

@William Bishop 

Hey, thanks for the detailed response!


Reply