Recherches récentes


Pas de recherche récente

Dylan McKinney's Avatar

Dylan McKinney

Adhésion le 12 oct. 2022

·

Dernière activité le 22 mai 2024

Suivis

0

Abonnés

0

Activité totale

11

Votes

3

Abonnements

4

APERÇU DES ACTIVITÉS

Dernière activité effectuée par Dylan McKinney

Dylan McKinney a ajouté un commentaire,

CommentaireSingle sign-on

Thanks to John Mahoney  for your response. I am using classic ASP.NET and didn't realize I needed a solution that worked from the client side. For me the solution was returning a page similar to this where it auto submits the form and triggers the redirect.

The Zendesk-provided github sample would be applicable if the user was submitting a form where the script is written client-side.

Afficher le commentaire · Publication le 22 mai 2024 · Dylan McKinney

0

Abonnés

0

Votes

0

Commentaire


Dylan McKinney a créé une publication,

Publication Developer - Zendesk APIs

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.

Publication le 29 nov. 2023 · Dylan McKinney

0

Abonnés

1

vote

0

Commentaire


Dylan McKinney a ajouté un commentaire,

Commentaire de la communauté Feedback - Apps and integrations (Platform)

Thanks for the quick response! It looks correct now.

Afficher le commentaire · Publication le 12 oct. 2022 · Dylan McKinney

0

Abonnés

0

Votes

0

Commentaire


Dylan McKinney a créé une publication,

Publication Feedback - Apps and integrations (Platform)

The documentation for the Bulk Delete Sessions endpoint lists the HTTP method as GET when it should be DELETE:

GET /api/v2/users/{user_id}/sessions


As done in the Using curl portion of the documentation, the -X DELETE argument indicates the DELETE HTTP method is to be used:

curl https://{subdomain}.zendesk.com/api/v2/users/{user_id}/sessions.json \  -v -u {email_address}:{password} -X DELETE

Publication le 12 oct. 2022 · Dylan McKinney

0

Abonnés

2

Votes

3

Commentaires