422 error when creating a ticket in Zendesk - zendesk

Question

I am developping an app in ASP.NET MVC5 using Zendesk_v2 (uploaded using a nuget package). I have admin rights for subdomain easynext.zendesk.com.
Here is my code for creating a ticket:
private static string requestUri = "https://easynext.zendesk.com/api/v2/tickets.json";
private static string _username = "gbalasel#easynext.be";
private static string _password = "MYPASSWORD";
private static ZendeskApi apiZendesk = new ZendeskApi(requestUri, _username, _password, "");
private void CréerTicketZendesk() {
var myTicket = apiZendesk.Tickets.CreateTicket(new Ticket()
{
Subject = "test ticket",
Priority = TicketPriorities.Low
});
}
This code sends me a 422 Unprocessable Entity error.
I have also made a test account for a client in Zendesk and the method works fine, the ticket is created in Zendesk and I also receive it in my email account.

Answer 1

Status 422 is most likely caused by a semantic error on your part. In my experience, ZD can return 422 most often in two situations:
When trying to PUT an update to a ticket whose status is closed. In that case, you need to create a new ticket or a follow-up ticket, if possible.
Setting an invalid value on some attribute of the ticket object or sub-object of the ticket. This can be particularly tedious to debug, as the ZD response doesn't usually tell you which attribute has an invalid value. You should check all the integer values that you are setting on the ticket. E.g., I've been burned by using the Group IDs from my production Zendesk while developing on the Sandbox System (they most likely have entirely different IDs for everything, including custom fields, groups, users, etc.).
If you are creating new tickets via POST, be sure to check all the values you are setting, as per my second bullet point above.

Answer 2

This telling you that you have not formed a request that it can handle; the destination script exists (otherwise you'd see a 404), the request is being handled (otherwise you'd get a 400 error) and it's been encoded correctly (or you'd get a 415 error) but the actual instruction can't be carried out.
take a look on this for more info.
Error List

Answer 3

just to add to the solution if anyone encounters the same problem.
requester_id is mandatory while posting the ticket json.
A sample ticket json -
{
"ticket": {
"subject": "My printer is on fire!",
"requester_id": 123,
"assignee_id": 456,
"type": "incident",
"subject": "Help, my printer is on fire!",
"description": "The fire is very colorful.",
"priority": "High",
"status": "open",
"custom_fields": [
{
"id": 111, // custom field ID
"value": "500.23"
}
]
}
}
Thanks

Answer 4

Yeah I run today to the same problem and solved it. The problem is that you need a comment and body part inside the ticket structure.
So this is how it could look like (in PHP):
$ticket = [
'group_id' => '35135',
'title' => 'Title',
'subject' => 'Subject',
'type' => 'ticket',
'comment' => ['body' => 'Comment text.'],
'priority' => 'normal',
'ticket_form_id' => '454524',
'custom_fields' => [
'51325351' => 'test',
],
];
Take a look on here:
https://developer.zendesk.com/rest_api/docs/core/tickets

Answer 5

I had an issue with the Zendesk API throwing a 422 when I was attempting to create a ticket. All parameters were correct, the problem was that the assignee for which the ticket was created for did not belong to the group.
I found this error by looking at the request response by using FIDDLER.

Answer 6

Adding this here in case someone else runs into this issue. For me the ticket formatting was correct, but the requester was suspended:
Error Result:
{
"error": "RecordInvalid",
"description": "Record validation errors",
"details": {
"requester": [{
"description": "Requester: jkraft is suspended."
}]
}
}
Follow these instructions to unsuspend a user: https://support.zendesk.com/hc/en-us/articles/4408835668634-How-do-I-unsuspend-access-for-a-user-

Answer 7

I hope this is helpful to tell whether or not you are receiving the HTTP 422 because the ticket was already closed or if its because you were trying to do something like edit a field with invald params:
If you log the response object from zendesk for the failed http 422, you can look at the response object and check its configs. In my example it was:
response: {
status: 422,
statusText: 'Unprocessable Entity',
headers: {
date: 'Wed, 01 Feb 2023 17:48:00 GMT',
'content-type': 'application/json; charset=utf-8',
'content-length': '145',
connection: 'close',
'x-zendesk-api-version': 'v2',
'x-zendesk-application-version': 'v15375',
'x-frame-options': 'SAMEORIGIN',
'zendesk-rate-limit-tickets-update': 'total=100; remaining=99; resets=60',
'x-rate-limit': '700',
'rate-limit': '700',
'x-rate-limit-remaining': '699',
'rate-limit-remaining': '699',
'rate-limit-reset': '60',
'strict-transport-security': 'max-age=31536000;',
'cache-control': 'no-cache',
'x-zendesk-origin-server': 'classic-app-server-5b7bb5f96b-2bngr',
'set-cookie': [Array],
'x-request-id': '792c83f6384a5f9a-SMF, 792c83f6384a5f9a-SMF',
'x-runtime': '0.086818',
'x-zendesk-zorg': 'yes',
'cf-cache-status': 'DYNAMIC',
'report-to': '{"endpoints":[{"url":"https:\\/\\/a.nel.cloudflare.com\\/report\\/v3?s=mwQlS2H5vr2L4HJeTbyCvhjJbRJIwwhO%2FjJFw1z5cpIkak9Oke5GtqcaWsrzIF9gnYxTnkiPAFpkBgprHoXcr2yi%2FvA7grLEoQvXeHhsSmzOnu2LslqRDbzYeeMhRRtQwIrE0uLhrZJxTzlo%2FIfcKZ4%3D"}],"group":"cf-nel","max_age":604800}',
nel: '{"success_fraction":0.01,"report_to":"cf-nel","max_age":604800}',
server: 'cloudflare',
'cf-ray': '792c83f6384a5f9a-SMF'
},
config: {
transitional: [Object],
adapter: [Function: httpAdapter],
transformRequest: [Array],
transformResponse: [Array],
timeout: 10000,
xsrfCookieName: 'XSRF-TOKEN',
xsrfHeaderName: 'X-XSRF-TOKEN',
maxContentLength: -1,
maxBodyLength: -1,
validateStatus: [Function: validateStatus],
headers: [Object],
baseURL: 'https://***.zendesk.com/',
method: 'put',
url: '/api/v2/tickets/69519.json',
data: '{"ticket":{"status":"open","comment":{"html_body":"Follow-up Notes: \\n<p><br></p>","public":false}}}'
},
If you will notice, the 'url' and 'data' properties of the config object in my case proved I was hitting the correct api endpoint and I was also providing the correctly formatted payload. This led me to pull the tickets status and confirm it was closed, which was the source reason for the 422 response.