422 error when creating a ticket in 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 = "[email protected]"; 
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.

Klan

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:

1. 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.
2. 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.

Anestassia

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

Sweptback

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

Basinet

This helped me out, thanks! It's worth noting that if "requester_id" is set to null, the ticket will be created with the currently (in your script) authenticated API user as the requester, at least this seems to be the case for me. Also, "description" is mandatory as well, and it cannot be an empty string. – Coattail

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

Organdy

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.

Elaterin

Answer 6

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.

Zita