---

title: How It Works description: The reverse-proxy architecture behind GuardProxy — request flow, method filtering, header forwarding, and response handling. group: Concepts order: 1

How GuardProxy Works

GuardProxy is a reverse proxy that runs on Cloudflare's global edge network. Every request your client makes flows through it before reaching the upstream API.

The architecture

AI Agent / Script / Dashboard
         |
         v
      GuardProxy
         |
    +---------+----------+
    |         |          |
  GET/HEAD  OPTIONS   POST/PUT/PATCH/DELETE
    |         |          |
    v         v          v
  Forward   Forward    403 Blocked
  to API    to API     + logged

Reads go straight through. Writes never reach the upstream.

Request flow

Each request passes through the same pipeline:

1. Parse the URL — extract the customer slug (subdomain) and upstream slug (first path segment).
2. Load config — look up the customer and upstream configuration.
3. Access check — verify the subscription/trial is active (a lapsed account returns 402).
4. Block decision — apply the path allowlist, then the method block (see below).
5. Forward — send the request to the upstream with headers intact.
6. Count — increment the usage counter for the month.

Method filtering

The filtering is simple and deliberate — that's what makes it trustworthy:

• GET, HEAD, and OPTIONS pass through to the upstream untouched.
• POST, PUT, PATCH, and DELETE are blocked with a 403 before they reach the upstream.

This works because REST APIs use HTTP methods as verbs. You don't need to understand the API's data model or business logic — you just filter by method. The check order matters: the path allowlist is evaluated first, so an allowlisted path is forwarded regardless of method.

Header forwarding

Your API key passes through GuardProxy untouched. The Authorization header and all other headers are forwarded to the upstream verbatim. Your key is never stored or logged — it exists in memory for the duration of the request and is gone when the response returns.

One deliberate exception: HTTP method-override headers (X-HTTP-Method-Override, X-Method-Override, and similar) are stripped before forwarding. These tell frameworks like Express and Rails to change the effective method — if forwarded, a GET could bypass the block and execute a DELETE at the upstream. Stripping them closes that bypass.

Path allowlists

Some APIs use POST for reads. GraphQL is the canonical example — all queries and mutations go over POST to a single endpoint. GuardProxy's path allowlist lets you exempt specific paths from the method block.

Add /graphql to the allowlist and POST requests to that path pass through. Every other path stays blocked. The allowlist matches on path prefix, so /graphql and /graphql/anything both match. See Path Allowlists for the full details — including the sharp edges.

Response handling

GuardProxy forwards the upstream response to the client verbatim — status code, headers, body, everything.

• If the upstream returns a 404, you get a 404.
• If it returns a 429 rate limit, you get the 429 with the upstream's Retry-After header.
• Redirects pass through as-is; the client sees the raw 302 and decides whether to follow it.
• All response headers — Set-Cookie, Content-Type, custom X-* headers — are forwarded unmodified.

GuardProxy never modifies the response. The only response it generates itself is the 403 block for write methods.