In a single controlled attempt with reported Web SDK version 1.104731.0, getById returned the expected Image item (type image). Board getInfo succeeded before and after the file call and matched the expected board. Image.getFile('preview') was invoked once and rejected after 3345 ms; no File was returned. Our privacy-preserving recorder retained only Error.name=Error and local classifier labels OTHER_TEXT/UNCLASSIFIED. Those labels are our own, not Miro error codes. The raw error message was not retained. The inspected public SDK source sends IMAGE_GET_BLOB for getFile and implements getDataUrl through getFile; this source inspection is not an independent attestation of the bytes executed in that attempt. We have not established the cause or verified effective scopes. Is there a supported Web SDK way to obtain a non-sensitive rejection code/category that distinguishes file permission, image conversion/delivery and lifecycle failures? Which documented file-specific preconditions should we check? No retry, alternate image API or account/scope change occurred within this attempt. No private board/item IDs, images, signed URLs or credentials are included here.
Web SDK Image.getFile('preview'): supported non-sensitive rejection diagnostics?
+1+1An additional observation, separate from the earlier preview attempt:
In one limited test from an app panel opened with openPanel, board identity and the requested image item's ID/type were verified. Calling getFile('original') once then rejected; no File was returned. The retained result was Error.name = Error, with no numeric code observed. We did not retain the raw error message, image data, or URLs.
This used an integrity-checked local copy of SDK client version 1.105778.0, not the normal SDK loading route. It is not a controlled comparison with the earlier attempt. We have not independently verified effective scopes or established a root cause.
The Image reference documents boards:read for getFile. Is there a supported way to distinguish file-specific access, conversion/delivery, and lifecycle failures without collecting the original error payload or signed URLs? If not, which documented prerequisites or minimal non-sensitive diagnostic fields should we use for a support inquiry?
We are looking for guidance, not requesting access changes, a retry, or a workaround that bypasses permissions.
+1A separate local-development observation, before any SDK or image API call:
In normal Chrome, a temporary app entry pointed to an HTTP localhost diagnostic page. The page contained static text only, with script execution and outbound connections disabled. The intended iframe source appeared in the Miro board DOM, but we could not confirm the diagnostic text became visible. The server's HTTP handler recorded zero requests during the trial. These counters are not packet tracing and exclude the separate local shutdown endpoint.
A user-provided screenshot of miro.com site settings showed Local network access as Ask (default). We did not change permissions. A single filtered console-error read returned no entries; this is not evidence that no browser error occurred. The installed Chrome version and the actual navigation failure reason have not been captured. The app entry was restored after each trial.
This is separate from the earlier getFile rejection, not proof of the same cause or a controlled SDK comparison.
Miro's deployment guide permits HTTP localhost for local development. Are there additional documented Chrome local-access or iframe prerequisites for this entry route? What is the smallest supported, non-sensitive diagnostic that distinguishes browser local-access gating, parent-frame policy, and connection failure before the SDK loads?
We are not requesting security bypasses or broader permissions. No private board/item IDs, images, raw logs, account details, or signed URLs are included.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.