## TL;DR
A 422 on a side-conversation email reply means the payload failed validation: usually the recipient address is missing or invalid, the side conversation is in a state that disallows replies, or required threading headers are absent. Validate the recipient and conversation state before sending, and keep the reply payload minimal. The fix is almost always in what you sent, not in Zendesk.

## The query

```text
zendesk side conversation 422 on email reply
```

## Use this when

- Side conversation replies return 422
- Automated side-conversation emails fail
- You are building side-conversation integrations
- Side conversation replies work manually but not via API

## Not for

- Using side conversations in the agent UI
- Regular ticket public replies
- Email deliverability or spam
- Side conversation Slack or Teams channels

## Steps

### 1. Read the 422 response body for the failing field

The 422 body names what failed validation. Read it before changing anything: recipient errors, state errors, and payload-shape errors each point at different fixes. Guessing wastes cycles.

Expected output: the exact failing field identified from the response.

### 2. Validate the recipient before sending

Confirm the side conversation has a valid email recipient: address present, well-formed, not a placeholder. Replies to conversations whose recipient was never set, or was set to an invalid address, 422 reliably.

Expected output: recipient validated on every automated reply path.

### 3. Check the side conversation state allows replies

Closed or archived side conversations reject new replies. Read the conversation state first and skip or reopen deliberately. Replying into a closed conversation is a state error, not a payload error.

Expected output: state checked before reply, closed ones handled explicitly.

### 4. Keep the reply payload minimal and well-formed

Send only the fields the endpoint needs: body, and threading references if required. Extra or mistyped fields are the most common 422 source in hand-rolled payloads. Minimal payloads have minimal validation surface.

Expected output: minimal payloads passing validation.

### 5. Log the full request and response on 422

Record the exact payload sent and the exact validation errors returned. Side-conversation 422s recur with new variants; the log turns each recurrence into a five-minute fix instead of a fresh investigation.

Expected output: request/response logging on every 422.

## Template: the checklist

```text
Side conversation 422:
[ ] 422 body read for the failing field first
[ ] Recipient validated before send
[ ] Conversation state checked for reply eligibility
[ ] Minimal, well-formed reply payloads
[ ] Full request/response logged on 422
```

## Variant phrasings

### side conversation reply failed validation

Steps 1 and 4. Read the body, minimize the payload.

### 422 creating side conversation email

Steps 2 and 3. Recipient and state.

### side conversation api error

Full sequence as the debugging order.

## Why it happens

Side conversations are a separate object from tickets with their own lifecycle and validation, but integrations often treat them like ticket comments with a recipient attached. The 422 is the API insisting on the distinction: recipients must be real, states must allow replies, payloads must match the side-conversation schema. Manual replies work because the UI enforces all of this silently.

## Edge cases

- Recipient changed mid-conversation: the stored recipient may no longer be valid. Re-validate, do not cache.
- HTML versus text bodies: malformed HTML in the body can fail validation. Sanitize or send text.
- Rate-limited retries: a 429 retry that replays a stale payload can 422 on state that changed. Re-read state before replay.
- Child tickets versus side conversations: they validate differently. Confirm which object the automation targets.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AA9WOJv-LhmCkiWrKr2Sxw