Trust the live API response, not the docs' field names. Capture a real response, diff its keys against what the client parses, and rename the fields - user_id to userId here - so parsing stops yielding nulls. Docs get written once and drift; the wire format is the truth.

```text
docs said the field was user_id  -  the live API returns userId and the generated client parsed everything as null
```

## Steps

1. Make a real request against the live API and save the raw response body exactly as returned.
   Expected: You have a real response saved, showing the actual key names.

2. List the actual key names in the response and compare them one by one against the field names in the generated client. Write down every mismatch.
   Expected: You have a complete list of field-name mismatches between the client and the live API.

3. Rename the client fields to match the live keys. If you prefer stable internal names, add an explicit mapping layer instead - but make the mapping match the wire format, not the docs.
   Expected: Every parsed field maps to a key that actually exists in the live response.

4. Re-run the parsing against a fresh live response and confirm fields populate with real values instead of null.
   Expected: Parsed objects contain real values for every field; no silent nulls remain.

## Use this when

- the client parses everything as null or empty despite successful requests
- the docs show snake_case while the API returns camelCase, or the reverse
- the client was generated from docs without ever checking a live response

## Not for this skill when

- fields are genuinely absent from responses - renaming will not conjure them
- the list is wrapped in an envelope the client does not unwrap
- a new enum value breaks a strict parser - that is a different drift problem

## Variant phrasings

### field name mismatch null
### user_id vs userId
### API returns different field names than docs
### parsed everything as null

## Why it happens

Naming conventions change between API versions while docs get written once and drift. The deeper trap is that lenient parsers turn a wrong field name into a silent null instead of an error: the request succeeds, the parse succeeds, and the data is quietly empty. It hides for days because nothing throws - until someone notices the dashboard is blank.

## Edge cases

- Some endpoints use different conventions than others in the same API - check per endpoint
- Versioned APIs may differ per version, so pin which version's names you mapped
- A mapping layer beats scattered renames when you control the internal schema
- Add a test asserting each parsed field is non-null on a fixture response so renames regress loudly

## Provenance

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