Inline images embedded via the API (html_text + <img data-asana-gid>) render at a tiny, non-adjustable size, unlike images pasted natively into the comment box.

English Forum Developers & API
1

Issue: Inline images embedded via the API (html_text + <img data-asana-gid>) render at a tiny, non-adjustable size, unlike images pasted natively into the comment box.

Setup: Using a Personal Access Token, I:

  1. Upload an image to a task via POST /tasks/{task_gid}/attachments (multipart, with correct Content-Type: image/png on the file part).
  2. Immediately reference it inline in a comment via POST /tasks/{task_gid}/stories with html_text: "<body>...<img data-asana-gid=\"{attachment_gid}\"/>...</body>", per your documented rich-text mechanism (Rich text).

What happens: The image does render inline and click-to-zoom works correctly. But it displays very small in the comment feed, and there’s no way I can find to control that — no width/height/style attribute I add to the <img> tag is honored (the docs also confirm no size-control mechanism exists for this).

Root cause I found by comparing raw html_text: I manually pasted the same image directly into the Asana web app’s comment box (native paste), then fetched that story’s html_text via GET /stories/{story_gid}?opt_fields=html_text for comparison against my API-created one:

  • Native paste produces: data-src-height="204" data-src-width="1135" data-thumbnail-url="https://asanausercontent.com/.../{gid}.{hash}_height640.png" data-thumbnail-height="115" data-thumbnail-width="640"
  • My API-created version produces: data-src-height="0" data-src-width="0" data-thumbnail-url="https://asanausercontent.com/.../{gid}.{hash}_height640.png" data-thumbnail-height="0" data-thumbnail-width="0"

Both have a real data-thumbnail-url pointing to a generated thumbnail file (so thumbnail generation did run), but the data-src-*/data-thumbnail-* dimension metadata stays 0 indefinitely for API-created attachments — I re-checked one over 2 hours after upload and it was still 0, so this isn’t an async-processing delay.

My question for Asana: Is there a way via the public API to trigger whatever server-side step populates data-src-width/data-src-height/data-thumbnail-width/data-thumbnail-height for an attachment — e.g., a different upload endpoint, an additional field on POST /attachments, or a processing/reprocessing call — so that images uploaded and inline-embedded via the API render at the same size as natively-pasted ones? Or is this a known limitation of the /tasks/{task_gid}/attachments endpoint versus whatever internal mechanism the web client uses for comment-box paste?

2

Hi @penguin and welcome to the Asana Forum!

Thank you for reporting this problem. What you are seeing is an expected attachment upload behavior. When you send a request to POST /attachments endpoint, the file is uploaded to our servers; however, its metadata discovery (e.g., defining the image dimensions) is run asynchronously for better performance of the API. This means that you get the GID and other details of the Attachment resource, but Asana still needs some time to process the image.

When you use the Attachment GID in the comment right after the upload call, the image’s height and width are incorrectly set to 0 because Asana hasn’t yet determined its dimensions. To make it work correctly and allow the API to set the correct image size, I would recommend adding a small delay (e.g., 1-5 seconds) between the upload and comment calls. This was also discussed in this forum thread.

In the Web App, this async job is handled as part of image pasting, which is why it also takes a bit longer to see the image appear in the text editor. I know we don’t document this in our API Reference directly, so it’s not easy to determine it yourself. To make sure this is clearer, I will work with our team to improve the documentation around this behavior.