---

title: Limitations description: The boundaries of method-level filtering — where GuardProxy helps and where it can't. group: Reference order: 3

Limitations

GuardProxy enforces read-only at the HTTP method layer — it blocks write verbs (POST, PUT, PATCH, DELETE by default) before they reach your upstream API. That model is simple, fast, and auditable, but it has boundaries worth knowing about before you rely on it.

GraphQL — can't separate queries from mutations

GraphQL sends both reads (queries) and writes (mutations) as POST requests to the same endpoint. GuardProxy blocks by HTTP verb and does not inspect request bodies, so it cannot tell a query from a mutation.

Blocking POST blocks both. Allowlisting the /graphql path (to let queries through) also lets mutations through — the path allowlist exempts an entire path from the method block.

Workaround: run two upstreams for the same API — one with /graphql allowlisted (for tools that need to query), one without (for strict read-only enforcement). Point read-only integrations at the second.

APIs that mutate on GET

A small number of APIs trigger state changes with GET requests (for example, GET /delete?id=123). Because GET is a read verb, GuardProxy will pass it through. GuardProxy filters by method, not by request semantics.

This is poor design on the vendor's side. If your API behaves this way, check with the vendor or route that path through a separate upstream with a stricter allowlist.

100 MB response cap

A single response larger than 100 MB is aborted and returns 413 response_too_large. The cap protects the proxy from streaming runaway responses. If an endpoint you need regularly returns large payloads, paginate or filter at the upstream API to stay under the limit.

Monthly request limit

Every plan has a hard monthly request cap: 20,000 on Free, 50,000 on Pro, and 250,000 on Team. Once your account reaches its limit (counting both allowed and blocked requests) in a calendar month, further requests return 429 until the counter resets at the start of the next cycle. Upgrade your plan anytime for a higher limit; if you need more than 250,000, contact us about a custom plan.

Request body cap

Inbound request bodies larger than 10 MB are rejected with 413 request_too_large before reaching the upstream. If an endpoint needs larger payloads, paginate or chunk at the source.

Method-level, not content-level

GuardProxy never inspects request or response bodies to decide what to allow. Filtering happens at the method and path level only. This means:

• It cannot block a specific field, parameter, or mutation inside an otherwise-allowed request.
• It cannot redact or mask data in a response.
• It cannot enforce row-level or object-level permissions.

If you need content-level controls, those belong at your upstream API's own authorization layer — GuardProxy is a method-level gate in front of it.