Problem using attachment_ids with Side Conversation API - "Attachment [ID] was not found" (ZAF App) | Community
Skip to main content

Problem using attachment_ids with Side Conversation API - "Attachment [ID] was not found" (ZAF App)

  • May 19, 2025
  • 4 replies
  • 0 views

Brad14

Hi Zendesk Developer Community,

We're developing a Zendesk App Framework (ZAF) v2 application that allows agents to send an email-type side conversation from a ticket, including attachments that already exist on that ticket.

Our Workflow:

  1. Fetch Ticket Attachments: Our ZAF app (running in the ticket sidebar) successfully fetches all comments for the current ticket using client.request({ url: \/api/v2/tickets/${ticketId}/comments.json` })`.
  2. Extract Attachment Details: We parse the attachments array from each comment, collecting unique attachment objects (which include id, file_name, content_url, etc.).
  3. User Selection: The app UI displays these attachments (filename and size) with checkboxes, allowing the agent to select which ones to include in the side conversation.
  4. Construct Payload: When the agent submits:
    • We gather the numeric id of each selected attachment.
    • We construct the payload for the POST /api/v2/tickets/{ticket_id}/side_conversations endpoint.
    • Based on API error feedback, we are formatting the attachment_ids parameter as an array of strings (e.g., ["12345", "67890"]).

The Issue:

When we make the client.request() call to create the side conversation, even with attachment IDs that we have verified exist on the target ticket's comments and are correctly formatted in the payload, we consistently receive a 422 Unprocessable Content error with the response body: {"error":"Attachment [ID] was not found"}

(Where [ID] is the specific attachment ID we provided).

Example Payload Sent:

JSON

 

{
  "message": {
    "type": "email",
    "subject": "Fax Transmission (Ticket #1111111)",
    "body": "This is the fax message body.",
    "to": [
      {
        "email": "fax_recipient@example.com"
      }
    ],
    "attachment_ids": [
      "22222222222222" // Example ID known to be on a comment in ticket #1111111
    ]
  }
}

 

Our Questions:

  1. Under what specific conditions would the Side Conversation API return {"error":"Attachment [ID] was not found"} for an attachment ID that is verifiably present on the target ticket's comments and correctly formatted in the API request?
  2. Are there any known issues, undocumented requirements, or specific states/permissions an attachment needs to be in (e.g., regarding its original comment being public/private, age, malware scan status if "malware_not_found" isn't sufficient) to be successfully used with the attachment_ids parameter when creating an email-type side conversation?
  3. Is there a potential delay for newly added ticket attachments to become "available" or "findable" by the Side Conversation API, even if they are immediately visible via the Comments API?

We've exhausted client-side troubleshooting for fetching and formatting these IDs. The API acknowledges the request structure as valid (it's not a general 400 Bad Request for structure anymore) but specifically cannot find the referenced attachment for use in the side conversation.

Any insights or guidance would be greatly appreciated!

Thank you.

4 replies

  • May 28, 2025
Hi Brad, 
 
Just wanted to let you know that I'm looking into this for you. With recent updates made to ZAF, I've had a few similar inquiries with client.request come up so I'm doing some testing and research to see if this is related to that. 
 
If you could share when this issue started for you that would be super helpful. 😊️

Brad14
  • Author
  • May 30, 2025

Hi Erica,

 

I first noticed the issue the week of 5/12.  I'm not sure of the exact date.  The ZAF app is new and that was the first time I was attempting to add attachments to a side conversation.

 

Hope this helps!


  • June 5, 2025
Hi Brad, 
 
Would you be okay with me opening a ticket for you? That way I can get some more info from you and help get you taken care of right away. 

Brad14
  • Author
  • June 5, 2025

Thank would be great, thanks Erica!