Match the versioning mechanism to the docs: this API versions by URL path, so version logic belongs in the base URL, not a custom header. The invented X-API-Version header was silently ignored, which is why the wrong version ran for a week with no error. Remove the header, pin the version in the path, and confirm which version actually answers.

```text
agent invented an X-API-Version header  -  the API versions via URL path and the header did nothing for a week
```

## Steps

1. Find the versioning rule in the provider docs: path segment, header, or query parameter. Quote the one sentence that states it so there is no ambiguity.
   Expected: You can state the documented versioning mechanism in one sentence.

2. Search the generated client for custom version headers, especially invented names like X-API-Version, and remove them. Version must not be set per request through a header the docs never define.
   Expected: No custom version header is sent anywhere in the client.

3. Set the version in the base URL in exactly one place, so every request carries it through the path. Keep it a named constant so bumping versions later is a one-line change.
   Expected: The base URL carries the version and there is a single constant to change.

4. Send a test request and confirm the response comes from the intended version: check the version field in the response, a docs-defined behavior difference, or the dashboard request log.
   Expected: A test request provably hits the intended API version and no stray version headers go out.

## Use this when

- the generated client sends a version header the docs never define
- the API versions via URL path but the client sets version elsewhere
- behavior matches a different API version than the one you expected

## Not for this skill when

- the API genuinely versions by header - then the header is correct and this skill does not apply
- the endpoint does not exist at any version - that is a phantom endpoint
- the docs and the live API disagree on versions - that is drift, a different fix

## Variant phrasings

### API version header ignored
### X-API-Version does nothing
### wrong API version in requests
### invented version header

## Why it happens

Header versioning is common in training data, so when docs are vague about the mechanism, the agent pattern-matches and invents a plausible header name. The trap is that unknown headers are silently ignored: the request still succeeds, against the default version, so there is no error to notice. The mistake only surfaces weeks later as subtle behavior drift.

## Edge cases

- Some APIs accept both path and header versioning - use the documented one and do not mix them
- Major version bumps change response shapes, so re-run parsing tests after pinning a new version
- Pinning too old a version misses security fixes - review the pinned version on a schedule
- Proxies and gateways sometimes strip unknown headers, which would have hidden this even in header-versioned APIs

## Provenance

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