zendesk api 422 Unprocessable Entity creating ticket

TL;DR

A 422 means Zendesk understood the request and rejected its contents. Read the response body's details array: it names each failing field and why. Fix those fields, not your auth headers or URL. Nine times out of ten it is a missing or malformed email on the requester, or a custom field with the wrong type.

The query

zendesk api 422 Unprocessable Entity creating ticket

Use this when

• POST /api/v2/tickets.json returns 422
• Tickets create fine in the agent UI but fail through your integration
• The response includes an error object with a details list

Not for

• 401 unauthorized responses (auth problem, not validation)
• 429 rate limit responses
• 403 forbidden responses (permission problem)

Steps

1. Read the details array, not just the status

The 422 body contains an error object whose details list gives field names and messages like 'Email: cannot be blank' or 'Custom field 3600123: must be an integer'. Log the full body; the status alone tells you nothing.

Expected output: a list of specific field-level complaints from Zendesk.

2. Fix the requester first

Ticket requesters need a name and a valid email. The most common cause: requester: { name: [name] } with no email, or an email with whitespace. Trim it, validate the format, and resend.

Expected output: the requester complaint disappears from the details array.

3. Check required and custom field types

If the requester is clean, look at custom fields: a text value sent to a numeric field, or a value not in a dropdown's option list, both 422. Compare each custom field id against the field definition in Admin to confirm the expected type.

Expected output: every custom field matches its declared type.

4. Verify subject, comment, and priority values

Subject and at least one comment are required for a new ticket. Priority must be one of urgent, high, normal, low; any other string 422s. A comment body of pure whitespace also counts as empty.

Expected output: a minimal payload with subject, one comment, and a valid priority returns 201.

5. Replay the exact payload against a test ticket

Once the 422s clear in isolation, replay the real integration payload field by field. Add fields back in groups until the 422 returns; the last group added contains the offender.

Expected output: the full production payload returns 201 in the test environment.

Variant phrasings

zendesk 422 invalid value for email

Step 2 covers it. Emails with leading spaces from form inputs are the classic trigger.

zendesk api ticket create returns unprocessable entity on custom fields

Step 3 covers it. Pull the field definitions from the API and compare types one by one.

Why it happens

Zendesk validates the ticket after authentication and routing, so a 422 means everything upstream (credentials, endpoint, rate limits) is fine and the payload itself is wrong. Integrations tend to build payloads from variables that are sometimes empty, and Zendesk rejects the empty ones that map to required fields.

Edge cases

• Deleted users: a requester email tied to a suspended end user can 422 on some plans. Check the user state.
• Form-mapped tickets: web form submissions can inject unexpected custom fields. Map them explicitly.
• Locale values: an invalid locale string on the ticket also 422s. Use ISO codes Zendesk recognizes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstgv-2kzK-JlwH1IO_RAF1w