Recent searches


No recent searches

Help Center API Create Article Attachment fails due to improper Content-Type deduction



Posted Nov 29, 2023

I am experiencing a new issue when creating a help center article attachment. When attempting to create the attachment, I receive a 400 status code and the following error:

{
    "errors": "content_type Expected asset of type application/xml but got audio/mpeg"
}

The endpoint I am using is documented here:

https://developer.zendesk.com/api-reference/help_center/help-center-api/article_attachments/#create-article-attachment

I have an application calling the following endpoint:

POST /api/v2/help_center/articles/{article_id}/attachments

The file in question has a proprietary file extension used by my organization, so common methods of deducing the file type may be unreliable. When sending a similar request in Postman, I must use multipart/form-data for the Content-Type header or I receive a 400 response with the following error:

{
    "errors": "No file provided"
}
 
The issue appears to be reproducible for specific files, but the behavior is inconsistent for other files with the same extension, which sometimes work. In some cases, my files are "detected" as application/xml whereas others are detected as application/octet-stream.
 
These proprietary file types are all based on xml. When referring to the "detected" Content-Type, that is the value of the "content_type" field for a GET request to the same URL.
 
I would like to note that these exact files were uploaded previously using the same endpoint in the past without issue. Another user's recent post mentions new issues with a previously accepted file type, which may be related:
 
Also worth noting that the Create Article Attachment code sample for Python in the documentation does not appear to supply a file for the attachment, and that specifying a Content-Type of application/json will not work for this endpoint (results in 422 - Unprocessable Entity).
 
I would appreciate any help or feedback with this! For now my workaround has been to wrap the affected files in a .zip, which appears to be supported so far.

0

0

0 comments

Please sign in to leave a comment.

Didn't find what you're looking for?

New post