Attachments

^{Questions or issues? Contact us at api-support@manus.ai.} Use this guide when rendering assistant_message.content returned by task.listMessages. The API returns the original message content from the task without rewriting file paths or Manus resource protocols. Use the surrounding response fields and the related APIs described below to resolve supported Markdown links or images in the application. Resolve each Markdown link or image destination by type:

Render HTTP and HTTPS destinations normally. Do not match them against attachment paths.
Resolve manus-webdev:// destinations as described in Website checkpoints.
Match absolute execution-environment paths against message attachments as described in File paths.
Remove link or image nodes that use another unsupported non-HTTP protocol.

When a file or Manus resource reference cannot be resolved with the required context, remove that link or image node from the rendered output. Preserve the surrounding message text. The API does not perform this rendering step for the application.

File paths

An assistant can reference an output file by its execution-environment path:

[Download the report](/home/ubuntu/report.pdf)

When the same message contains a matching attachment, attachments[].path identifies that reference and attachments[].url provides the downloadable HTTP/HTTPS URL:

{
  "assistant_message": {
    "content": "[Download the report](/home/ubuntu/report.pdf)",
    "attachments": [
      {
        "type": "file",
        "filename": "report.pdf",
        "content_type": "application/pdf",
        "path": "/home/ubuntu/report.pdf",
        "url": "https://private.manuscdn.com/...",
        "file_uid": "FILE_UID",
        "version_uid": "VERSION_UID"
      }
    ]
  }
}

Parse the Markdown link or image destination, URL-decode it once, and compare it with attachments[].path. After a match, use attachments[].url as the link destination or image source. If no attachment matches this execution-environment path, remove the link or image node from the rendered output. Do not request path directly: it is a path inside the task’s execution environment, not a public URL. path is optional. It is omitted for attachments that do not have a usable execution-environment path. Download URLs are temporary. If a URL stops working, call task.listMessages again to read the current attachment URL. Do not persist a signed URL as permanent file identity. When present, use file_uid and version_uid to correlate the source output file and version across messages.

No v2 endpoint accepts either UID as input, and neither resolves a download URL.
They are unrelated to the file_id of temporary input files from file.upload, and to the website checkpoint version_id in manus-webdev:// links.
The same file_uid can appear in different tasks with different url values. Do not assume it belongs to the current task.
A transformed download, such as slides_format=pptx or markdown_format=docx, returns derived bytes while the UIDs still identify the source attachment version.

Cover images

Pass include_cover=true to task.listMessages to receive a thumbnail for each assistant_message attachment. Without it, attachments carry no cover fields. Send the parameter only when rendering covers; routine polling does not need it. Each attachment then carries cover_image_status:

ready — cover_image holds the cover URL.
pending — a cover is supported but not available yet. Treat an attachment that stays pending for several minutes as having no cover.
unsupported — this attachment has no cover.

If the cover lookup fails for a response, both fields are omitted from every attachment; read them from the next response. Which attachments have a cover depends on the file type:

Attachment	Cover	When it is generated
Manus Slides (`type: "slides"`)	First slide	When the slides are generated. Usually `ready` on the first request. `pending` while that render is still running or after it failed; this request does not start a render.
PDF (`pdf`)	First page	When the agent writes the file. Usually `ready` on the first request. If `pending`, this request starts generation; call again with `include_cover=true` after 10 to 15 seconds.
Spreadsheets (`xls`, `xlsx`, `csv`, `ods`)	First sheet	Same as PDF.
Images (`type: "image"`)	None, `unsupported`	Render `url` directly.
Markdown, Word, text, code, audio, video, archives, and every other type	Normally none, `unsupported`	Not generated. A file that already has a cover from an earlier Manus feature reports `ready`; always follow `cover_image_status` rather than the file type.
Any attachment without `file_uid`	None, `unsupported`

A cover belongs to the file, not to the message. When a later turn edits the same file, every attachment with that file_uid shows the cover of the most recently rendered version. Deduplicate covers by file_uid, not by URL: cover_image is re-signed on every response and each URL is valid for 48 hours. Read a fresh URL from the next response instead of storing one. artifact.list returns cover_image and cover_image_status with the same meanings for Library artifacts, but never starts PDF or spreadsheet cover generation; see Artifacts.

Website checkpoints

A website result can appear as a Markdown destination in this form:

manus-webdev://<version_id>

The value after the scheme is the checkpoint version_id for the website attached to the current task. Call website.listCheckpoints with the same task_id, then match the value against data[].version_id. If the checkpoint cannot be resolved, remove the link node from the rendered output. Website checkpoint version_id and attachment version_uid are unrelated identifiers. Do not use an attachment version_uid with website.listCheckpoints. Use website.status to read the current published URL and version. A checkpoint’s successful generation status does not mean that version is currently published.

Getting Started

API Reference

File paths

Cover images

Website checkpoints

Other link protocols

​File paths

​Cover images

​Website checkpoints

​Other link protocols

File paths

Cover images

Website checkpoints

Other link protocols