## TL;DR

Drop the removed field from the request payload the generated client builds, redeploy, and the 422s go away. The docs are stale: the live API removed the field and its validator now rejects anything it does not recognize.

The lasting fix is a doc-drift check: re-read the docs or changelog before regenerating, and treat any 422 naming a specific field as a removed-or-renamed field until proven otherwise.

## Verbatim query

```text
generated client sends a field the docs marked required  -  the live API removed it last month and now rejects it with 422
```

## Steps

1. Find the exact field the API rejects
   Run one failing call against the API and read the 422 response body; it usually names the offending field.
   Match that name to the field in your generated client payload builder.
   Expected: The 422 body names one specific field, and you can point to where your code sends it.

2. Confirm the live API really dropped it
   Check the provider changelog and the current docs for that field; look for a deprecation or removal note.
   Send a probe request without the field to confirm it now succeeds.
   Expected: The changelog or current docs show the field as removed, and a field-free probe returns 2xx.

3. Remove the field from the generated client
   Delete the field from the payload builder or comment it out behind a flag, then regenerate or patch the generated code.
   Update any tests that asserted the field was present.
   Expected: The generated payload no longer contains the field.

4. Redeploy and verify
   Ship the patched client and re-run the previously failing calls.
   Watch for 422s for a full sync cycle, not just one call.
   Expected: No more 422s across a full run; every call returns 2xx.

5. Add a drift guard
   Add a smoke test that sends a minimal payload and fails loudly if a 422 names a field you send.
   Schedule a monthly re-check of the changelog for the endpoints you integrate with.
   Expected: A future field removal trips the smoke test in CI instead of failing in production.

## Use this when

- Your generated client sends a field and the API answers 422 naming that field
- The docs call a field required while the provider changelog says it was removed
- A working integration broke with no client change on your side

## Not for this skill when

- The 422 names a field you know the API still accepts - that is a value or type problem, not a removed field
- Failures come back as 401 or 403 - that is auth, not payload shape
- Every field 422s - the endpoint path or API version is probably wrong

## Variant phrasings

### API rejects unknown field with 422
Same symptom when an API removes any parameter: strict validators reject unknown fields even when the docs still list them as required.

### docs say required but API says 422
The classic stale-docs tell: if the error names the field and the field worked last month, suspect a silent removal before blaming your code.

### 422 after no client change
When nothing changed on your side and calls start failing, the provider shipped something. Check the changelog before debugging your code.

## Why it happens

Docs get written once and the API keeps evolving. A field removal ships in a backend deploy, the validator starts rejecting unknown fields, and the docs still say required because nobody updated the page. Your generated client trusts the docs, so it keeps sending the field and every call 422s.

## Edge cases

- Some APIs warn first with a deprecation header before removing - check response headers for sunset warnings so you catch the next one early
- If the field is required by your database schema, map it to an internal-only field instead of sending it to the API
- Batch endpoints may reject the whole batch on one bad record - isolate failing records to confirm it is the field and not the batch

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QHorNZmA30cRcrbdZeg-8A