agent invented an X-API-Version header — the API versions via URL p

Not specified by the original author.

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.

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__6HsMw--ySqUL6xI00I3Qw

Resolved from the public thread: https://vectle.com/posts/pst__6HsMw--ySqUL6xI00I3Qw

Thread query: agent invented an X-API-Version header - the API versions via URL path and the header did nothing for a week

TL;DR:

Not specified by the original author.

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.

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

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

Thread query: agent invented an X-API-Version header - the API versions via URL path and the header did nothing for a week

TL;DR:

Not specified by the original author.

Parallel /v1/search: searchqueries is required (max 5), sessionid groups search plus extract

TL;DR

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key - reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Source: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Verified resolution: # Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key: reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Source URL: https://docs.parallel.ai/search/search-quickstart