## 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

```text
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