zendesk api error "422 unprocessable entity" creating ticket via api

Not specified by the original author.

TL;DR

A Zendesk 422 on ticket creation almost always means the request failed validation, not that the API is broken. The response body names the offending field, and the usual suspects are a missing requester, an invalid custom field value, or a dropdown tag that does not exist. Read the error details first, fix the field, and retry with a minimal payload to isolate which field is wrong.

The query

zendesk api error "422 unprocessable entity" creating ticket via api

Use this when

• POST /api/v2/tickets.json returns 422 Unprocessable Entity
• Bulk imports report per-record 422 failures
• A ticket create that worked in staging fails in production
• You are building or maintaining a Zendesk ticket creation integration

Not for

• 401 Unauthorized (credential or token problems)
• 429 rate limiting (throttling, not validation)
• Tickets failing to create from email or web form
• Agent UI errors when manually creating tickets

Steps

1. Read the error details in the response body

A 422 always carries a details object naming the field and the rule it broke, for example a requester error or an invalid custom field value. Log the full body. The top-level message alone never tells you which field failed.

Expected output: the exact field and rule from the details payload.

2. Verify the requester block

Ticket creation requires a valid requester identity. Confirm the requester email parses, the name is present, and you are not passing both an existing user id and a conflicting email. Anonymous tickets still need the requester object with a name or email.

Expected output: requester email and name confirmed valid, no id/email conflict.

3. Validate every custom field value against its type

Dropdowns accept only defined tag values, dates must be ISO format, checkboxes take true or false. A free-text value sent to a dropdown field is the most common 422. Pull the ticket field definitions and compare each value you send.

Expected output: each custom field value matches its declared type and allowed values.

4. Strip the payload to a minimal ticket and retry

Send only subject, comment body, and requester. If the minimal ticket creates, add fields back one at a time until the 422 returns. That pinpoints the field faster than guessing.

Expected output: a minimal ticket creates successfully, or still 422s (meaning the problem is auth/scope, not fields).

5. Check field permissions and required-on-solve settings

Fields marked required in the admin UI can reject API creates missing them. Confirm the API credential has permission to set every field you send, especially restricted custom fields.

Expected output: required fields identified, permissions confirmed.

Template: the diagnosis checklist

422 on ticket create:
[ ] Response details read: failing field = ____, rule = ____
[ ] Requester email valid, no id/email conflict
[ ] Each custom field value matches its type (dropdown tags verified)
[ ] Minimal payload (subject + comment + requester) retried
[ ] Required and restricted fields checked against API permissions
Fix the named field, retry, then rebuild the full payload field by field.

Variant phrasings

422 creating ticket with custom fields

Step 3 first. Dropdown tag mismatches cause most of these.

zendesk api ticket create validation failed

Steps 1 and 2. The details payload and the requester block.

bulk import 422 errors

Step 4 in a loop: isolate the failing field per record, fix the mapping once.

Why it happens

The tickets endpoint validates the payload against the instance's ticket fields, user records, and permissions before writing anything. Because instances differ (custom fields, required fields, dropdown options), a payload that works on one instance 422s on another. The 422 is the API telling you the payload does not match this instance's rules.

Edge cases

• Sandbox to production drift: dropdown tags and required fields differ between instances. Re-pull field definitions per instance.
• End-user versus agent creates: end-user tokens cannot set some fields agents can. The same payload behaves differently by credential.
• Locale-sensitive date fields: a valid ISO date in one locale format can still fail if the field expects a different pattern.
• Deleted users as requesters: referencing a deleted user id 422s. Resolve to an active identity first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sAtkkSgbbJUF7k0dEzHqBA

Resolved from the public thread: https://vectle.com/posts/pst_sAtkkSgbbJUF7k0dEzHqBA

Thread query: zendesk api error "422 unprocessable entity" creating ticket via api

TL;DR: A Zendesk 422 on ticket creation almost always means the request failed validation, not that the API is broken. The response body names the offending field, and the usual suspects are a missing requester, an invalid custom field value, or a dropdown tag that does not exist. Read the error details first, fix the field, and retry with a minimal payload to isolate which field is wrong.

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

Zendesk 422 on ticket create or update: closed tickets and bad attribute values

TL;DR

When Zendesk returns 422 on a ticket write, first check the ticket is not closed, then audit every attribute value you set, especially IDs. If you develop against a sandbox, re-resolve group, user, and custom field IDs in the sandbox rather than copying them from production. Context: Stack Overflow #22867369 (accepted answer, 6 votes): the asker's ticket creation code returned a bare 422 with no useful detail.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

The top-voted answer (6 votes) names the two usual causes: trying to update a ticket whose status is already closed, which requires creating a new or follow-up ticket instead, and setting an invalid value on some ticket attribute or sub-object. The second one is nasty to debug because the response rarely says which attribute failed, and one classic trap is using production IDs for groups, users, or custom fields while developing against a sandbox, where the IDs differ.

Source: Stack Overflow #22867369 (accepted answer, 6 votes): the asker's ticket creation code returned a bare 422 with no useful detail. The top-voted answer (6 votes) names the two usual causes: trying to update a ticket whose status is already closed, which requires creating a new or follow-up ticket instead, and setting an invalid value on some ticket attribute or sub-object. The second one is nasty to debug because the response rarely says which attribute failed, and one classic trap is using production IDs for groups, users, or custom fields while developing against a sandbox, where the IDs differ.

Verified resolution: When Zendesk returns 422 on a ticket write, first check the ticket is not closed, then audit every attribute value you set, especially IDs. If you develop against a sandbox, re-resolve group, user, and custom field IDs in the sandbox rather than copying them from production.

Source URL: https://stackoverflow.com/questions/22867369/422-error-when-creating-a-ticket-in-zendesk