v2 API - Programmatic access to attachments on tickets and conversations

Programmatic access to attachments on tickets and conversationsMany of our tickets contain screenshots, screen-recordings, log files, and other binary attachments — both in the original ticket description/body and in subsequent conversation entries (replies, notes, customer screenshots). Our integration needs to retrieve those bytes so we can pass them to downstream tools (LLM agents, automated reproductions, etc.).Current stateWhen we fetch a ticket via GET /api/v2/tickets/{id}?include=conversations,requester,tags, the response describes attachments structurally — we can see filenames and sizes — but we can't retrieve the actual file content via the public API. There appears to be no attachments array with downloadable URLs at either the ticket level or per conversation entry, and no GET /attachments/{id} endpoint.Inline images embedded in the HTML body of a description or conversation reference Freshservice CDN URLs that require authenticated session cookies, not API key auth, so they can't be fetched programmatically.PM task descriptions/comments have the same limitation.What we'd like — any of these would solve it  - A (preferred): Include an attachments[] array on each ticket and on each conversation entry, where each entry has at minimum { id, name, content_type, size, attachment_url } and attachment_url is fetchable withthe same API-key auth used elsewhere (or a short-lived signed URL).  - B: A dedicated endpoint: GET /api/v2/attachments/{id} returning the binary, authenticated with the same API key.  - C: Make inline image URLs in HTML bodies API-key-fetchable (i.e. accept Authorization / basic-auth on those CDN paths) so we can resolve the <img src="..."> references already present in body/description.  - D: Same treatment for the PM task API — attachments on PM tasks and PM task comments should be retrievable the same way.Inline content-type info and size up-front (without an extra round trip) would let us decide whether to pull a file at all, which matters for large screen recordings.  ---Why it mattersA meaningful fraction of bug reports are only useful with the screenshot or recording — text alone doesn't reproduce the issue. Today our tooling has to surface "see the ticket in the browser" as a fallback, breaking the automation loop.