## 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

```text
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

```text
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