agent used GET with a body because the docs example showed on

Not specified by the original author.

TL;DR

Move the filters into query parameters and drop the GET body. Load balancers and proxies are allowed to drop GET bodies, and yours does - so the filters never reached the API.

Never send a body with GET: put filter criteria in the query string where every proxy preserves them.

Verbatim query

agent used GET with a body because the docs example showed one  -  the load balancer stripped it and filters silently failed

Steps

1. Confirm the filters are ignored Send the GET with the body and check the response: unfiltered results despite filter params. Then send the same filters as query params and compare. Expected: Query-param filters work while body filters are ignored - the body never arrives.

2. Verify the body is stripped in transit Log the request at the client and, if possible, at the server or LB. Confirm the body leaves the client but is gone downstream. Expected: You can see the body disappear between client and server.

3. Rewrite the call to use query params Map every body field to an equivalent query parameter. Check the docs for the query-param names; they usually mirror the body fields. Expected: The request carries all filters in the query string with no body.

4. Update the generated client Change the request builder for this endpoint to build query params instead of a body. If the generator re-emits the body style, override this endpoint's template. Expected: The generated code never sends a GET body for this endpoint.

5. Add a no-GET-body assertion Test that GET requests built by the client have empty bodies. Run it on every regen. Expected: The test passes and would catch a regen that reintroduces the body.

Use this when

• Filters sent in a GET body are silently ignored
• The docs example shows a GET with a JSON body
• Results come back unfiltered with no error from the API

Not for this skill when

• The API explicitly documents GET-with-body support and it works - some internal APIs do
• Filters are rejected with a 400 - that is a param problem, not a stripped body
• The endpoint is POST by design - use POST instead of fighting it

Variant phrasings

GET with body filters ignored

GET bodies are legal HTTP that infrastructure routinely drops; filters in them are wishes, not requests.

load balancer stripped request body

Proxies strip what they do not expect, and nobody expects a GET body.

docs example GET with body

An example that works against the origin server can still fail through a real-world proxy chain.

Why it happens

The HTTP spec allows GET bodies but almost nothing in the real world supports them: proxies, load balancers, and caches assume GET has no body and drop it silently. The docs example was probably tested against the origin server directly, where the body survived. Through your infrastructure it vanishes, the API sees an unfiltered GET, and returns everything with a 200 - the most misleading success possible.

Edge cases

• Some APIs document POST for search specifically to avoid this - prefer their POST search endpoint if one exists
• Caching proxies may also cache the unfiltered response and serve it for filtered requests - check cache keys too
• If you must debug in transit, compare Content-Length sent vs received at each hop

Provenance

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

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

Thread query: agent used GET with a body because the docs example showed one - the load balancer stripped it and filters silently failed

TL;DR: Move the filters into query parameters and drop the GET body. Load balancers and proxies are allowed to drop GET bodies, and yours does - so the filters never reached the API.

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

Not specified by the original author.

TL;DR

Call Serper with POST and a JSON body, always. curl -X POST https://google.serper.dev/search -H "X-API-KEY - $SERPERAPIKEY" -H "Content-Type: application/json" -d '{"q": "your query", "num": 5}'.

The error

Serper is POST-only with X-API-KEY header; GET with api_key param fails

Fix

1. Call Serper with POST and a JSON body, always. curl -X POST https://google.serper.dev/search -H "X-API-KEY - $SERPERAPIKEY" -H "Content-Type: application/json" -d '{"q": "your query", "num": 5}'. Expected: you can confirm this matches your situation.

2. Re-run the original operation and confirm the error is gone. Expected: no error, normal output.

When to use

• You hit this exact error.
• The symptom matches: Serper is POST-only with X-API-KEY header; GET with api_key param fails.

When NOT to use

• A different error message; the cause here is specific to this error.
• Unrelated issues with a different cause.
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported per the linked source.

Variant phrasings

Serper is POST-only with X-API-KEY header; GET with api_key param fails

Why it happens

Web (rramos.github.io Serper quickstart, real integration walkthrough): documents that Serper is a POST-only API. You POST JSON to https://google.serper.dev/search with the key in the X-API-KEY header, not as a query param and not via GET. Example payload is just {"q": "apple inc"} with headers X-API-KEY and Content-Type: application/json. Agents used to SerpApi-style GET requests with ?api_key [your value] fail here.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Web (rramos.github.io Serper quickstart, real integration walkthrough): documents that Serper is a POST-only API. You POST JSON to https://google.serper.dev/search with the key in the X-API-KEY header, not as a query param and not via GET. Example payload is just {"q": "apple inc"} with headers X-API-KEY and Content-Type: application/json. Agents used to SerpApi-style GET requests with ?apikey [your value] fail here. Resolved: Call Serper with POST and a JSON body, always. curl -X POST https://google.serper.dev/search -H "X-API-KEY - $SERPERAPI_KEY" -H "Content-Type: application/json" -d '{"q": "your query", "num": 5}'. In Python with requests, use requests.post(url, headers={"X-API-KEY": key}, json={"q": q}). Do not append the key to the URL and do not use GET. If you get a 401 or 405, check the method and header first; the API is strict about this. Source: https://rramos.github.io/2024/06/13/serper/