zuplo 6.71.21 → 6.71.23

package/docs/dev-portal/zudoku/components/landing-page.mdx

@@ -56,8 +56,8 @@ page for product-focused portals. The previews on this page are presented in a
     title="Build with our API"
     description="Everything you need to integrate payments, webhooks, and more — in minutes, not days."
     actions={[
-      { label: "Get started", href: "/docs/getting-started" },
-      { label: "API Reference", href: "/docs", variant: "outline" },
+      { label: "Get started", href: "/getting-started" },
+      { label: "API Reference", href: "/", variant: "outline" },
     ]}
     features={[
       {
@@ -121,7 +121,7 @@ front.
     title="Ship anywhere in the whole universe"
     description="Create and manage shipments, track packages in real-time, and integrate with multiple carriers through a single interface."
     actions={[
-      { label: "Get started", href: "/docs/getting-started" },
+      { label: "Get started", href: "/getting-started" },
       { label: "View on GitHub", href: "https://github.com/zuplo/zudoku", variant: "outline" },
     ]}
     aside={
@@ -183,25 +183,25 @@ routes visitors to the right section quickly.
         icon: <RocketIcon />,
         title: "Getting Started",
         description: "Set up your account and make your first request.",
-        href: "/docs/getting-started",
+        href: "/getting-started",
       },
       {
         icon: <BookOpenIcon />,
         title: "Guides",
         description: "Step-by-step tutorials for common use cases.",
-        href: "/docs",
+        href: "/",
       },
       {
         icon: <CodeIcon />,
         title: "API Reference",
         description: "Complete reference for every endpoint and type.",
-        href: "/docs",
+        href: "/",
       },
       {
         icon: <WebhookIcon />,
         title: "Webhooks",
         description: "Listen to events and build real-time integrations.",
-        href: "/docs",
+        href: "/",
       },
     ]}
   />

package/docs/dev-portal/zudoku/components/link.mdx

@@ -17,7 +17,7 @@ import { Link } from "zudoku/components";
 ### Basic Internal Link
 
 ```tsx
-<Link to="/docs/getting-started">Get Started</Link>
+<Link to="/getting-started">Get Started</Link>
 ```
 
 ### Link with State
@@ -39,7 +39,7 @@ import { Link } from "zudoku/components";
 ### External Link Behavior
 
 ```tsx
-<Link to="/docs" reloadDocument>
+<Link to="/" reloadDocument>
   Full Page Reload
 </Link>
 ```
@@ -53,7 +53,7 @@ function Navigation() {
   return (
     <nav>
       <Link to="/">Home</Link>
-      <Link to="/docs">Documentation</Link>
+      <Link to="/">Documentation</Link>
       <Link to="/api">API Reference</Link>
       <Link to="/blog">Blog</Link>
     </nav>
@@ -69,7 +69,7 @@ function Breadcrumbs({ path }) {
     <div className="breadcrumbs">
       <Link to="/">Home</Link>
       <span>/</span>
-      <Link to="/docs">Docs</Link>
+      <Link to="/">Docs</Link>
       <span>/</span>
       <span>{path}</span>
     </div>
@@ -134,7 +134,7 @@ function ConditionalLink({ to, disabled, children }) {
 ### Hash Links
 
 ```tsx
-<Link to="/docs/api#authentication">Authentication Section</Link>
+<Link to="/api#authentication">Authentication Section</Link>
 ```
 
 ## Advanced Usage

package/docs/dev-portal/zudoku/configuration/footer.mdx

@@ -59,7 +59,7 @@ footer: {
       links: [
         { label: "Features", href: "/features" },
         { label: "Pricing", href: "/pricing" },
-        { label: "Documentation", href: "/docs" },
+        { label: "Documentation", href: "/" },
         { label: "GitHub", href: "https://github.com/org/repo" }, // Auto-detected as external
       ],
     },
@@ -184,7 +184,7 @@ footer: {
       links: [
         { label: "Features", href: "/features" },
         { label: "Pricing", href: "/pricing" },
-        { label: "Documentation", href: "/docs" }
+        { label: "Documentation", href: "/" }
       ]
     },
     {

package/docs/dev-portal/zudoku/configuration/overview.md

@@ -46,7 +46,7 @@ const config: ZudokuConfig = {
     },
     { type: "link", to: "api", label: "API Reference" },
   ],
-  redirects: [{ from: "/", to: "/docs/introduction" }],
+  redirects: [{ from: "/", to: "/introduction" }],
   apis: {
     type: "file",
     input: "./apis/openapi.yaml",

package/docs/dev-portal/zudoku/guides/redirects.md

@@ -85,7 +85,7 @@ signal a permanent move; the JavaScript redirect used on generic static hosts is
 The most common use of redirects is setting a landing page for the root path of your portal:
 
 ```ts
-redirects: [{ from: "/", to: "/docs/introduction" }];
+redirects: [{ from: "/", to: "/introduction" }];
 ```
 
 This sends visitors who arrive at your portal's root URL to your introduction page.
@@ -98,7 +98,7 @@ external links continue to work:
 ```ts
 redirects: [
   { from: "/api/authentication", to: "/guides/auth-overview" },
-  { from: "/api/getting-started", to: "/docs/quickstart" },
+  { from: "/api/getting-started", to: "/quickstart" },
   { from: "/reference", to: "/api" },
 ];
 ```

package/docs/guides/proxying-between-zuplo-gateways.mdx

@@ -2,9 +2,8 @@
 title: Proxying Between Zuplo Gateways
 sidebar_label: Proxying Between Gateways
 description:
-  Learn how to proxy requests from one Zuplo project to another using the URL
-  Forward Handler or a custom fetch handler, propagate authentication, surface
-  upstream errors, and troubleshoot 522 timeouts.
+  Learn how to proxy requests from one Zuplo gateway to another, propagate
+  authentication, handle upstream errors, and fix 522 timeouts.
 tags:
   - backends
   - deployment

package/docs/policies/_index.md

@@ -43,7 +43,8 @@
 | formdata-to-json-inbound | Form Data to JSON | Converts form data in the incoming request to JSON. | api-gateway |
 | galileo-tracing-inbound | Galileo Tracing | Galileo Tracing Inbound Policy | ai-gateway |
 | geo-filter-inbound | Geo-location filtering | Block requests based on geo-location parameters: country, region code, and ASN | api-gateway |
-| graphql-analytics-outbound | GraphQL Analytics | Reports GraphQL errors returned in response bodies to Zuplo's GraphQL analytics. GraphQL servers following the standard Apollo / graphql-yoga pattern return `200 OK` with an `errors[]` array in the body when an operation fails, which HTTP-level analytics alone report as a success — add this policy to a GraphQL route and failed operations show up as failures on the GraphQL dashboard, classified by error type.  Each error in `errors[]` is classified from its `extensions.code` following the Apollo Server conventions (`GRAPHQL_PARSE_FAILED` → `syntax`, `GRAPHQL_VALIDATION_FAILED` → `validation`, `UNAUTHENTICATED` / `FORBIDDEN` → `auth`, timeout codes → `timeout`); custom codes can be mapped with `errorCodeClassification`, and anything unrecognized falls back to `defaultErrorClass` (`resolver`). Optionally set `logErrors` to also write a structured warning per errored response. Bodies larger than `maxResponseBytes` (default 5 MiB) are not inspected.  The response always passes through unchanged — the body is read from a clone, and any internal failure is swallowed so reporting can never break the request. The route must be marked `x-graphql: true` in `routes.oas.json` (which enables GraphQL analytics for the route); without the marker the policy logs a warning and does nothing. | api-gateway |
+| graphql-analytics-outbound | GraphQL Analytics | Reports GraphQL errors returned in response bodies to Zuplo's GraphQL analytics. GraphQL servers following the standard Apollo / graphql-yoga pattern return `200 OK` with an `errors[]` array in the body when an operation fails, which HTTP-level analytics alone report as a success — add this policy to a GraphQL route and failed operations show up as failures on the GraphQL dashboard, classified by error type.  Each error in `errors[]` is classified from its `extensions.code` following the Apollo Server conventions (`GRAPHQL_PARSE_FAILED` → `syntax`, `GRAPHQL_VALIDATION_FAILED` → `validation`, `UNAUTHENTICATED` / `FORBIDDEN` → `auth`, timeout codes → `timeout`); custom codes can be mapped with `errorCodeClassification`, and anything unrecognized falls back to `defaultErrorClass` (`resolver`). Optionally set `logErrors` to also write a structured warning per errored response. The policy reads up to `maxScanBytes` of the body (128 KiB by default, 5 MiB maximum), scanning it for the `errors` token; a response larger than that is treated as error-free. When the token is found and the body fits, it is parsed and its errors reported.  The response always passes through unchanged — the body is read from a clone, and any internal failure is swallowed so reporting can never break the request. The route must be marked `x-graphql: true` in `routes.oas.json` (which enables GraphQL analytics for the route); without the marker the policy logs a warning and does nothing. | api-gateway |
+| graphql-cache-inbound | GraphQL Cache | Caches GraphQL query responses at the edge so identical queries are served without a round-trip to the origin.  Unlike CDN caching that keys on the raw request body, this policy parses the GraphQL document and normalizes it before hashing: insignificant whitespace, field formatting, and fragment layout are collapsed, and variable object keys are sorted. Two requests that are semantically identical therefore share a cache entry even when their bodies differ byte-for-byte. There is no query size or nesting-depth limit.  Only `query` operations are cached. Mutations, subscriptions, malformed documents, and non-JSON bodies are forwarded to the origin untouched. Cache hits and misses are reported on the `x-cache` response header, with a short key fingerprint on `x-cache-key`.  To avoid serving one user's data to another, requests carrying an `authorization` or `cookie` header are not cached by default. Use `cacheKeyHeaders` to opt into caching them: each listed header's value is included in the cache key, so distinct credentials get distinct cache entries. | api-gateway |
 | graphql-complexity-limit-inbound | GraphQL Complexity Limit | Policy that limits the complexity and depth of GraphQL queries to prevent abuse. Protects your GraphQL API from expensive queries that could cause performance issues or denial of service attacks. | api-gateway |
 | graphql-disable-introspection-inbound | GraphQL Disable Introspection | Policy that disables GraphQL introspection queries in production. Introspection allows clients to discover the schema, which can be a security risk as it exposes your entire API structure. | api-gateway |
 | graphql-introspection-filter-outbound | GraphQL Introspection Filter | Filters GraphQL introspection responses to exclude specific types and fields.  This policy intercepts GraphQL introspection query responses and removes configured types and fields from the schema. Useful for hiding internal types or sensitive fields from the public schema. | api-gateway |

package/docs/policies/graphql-analytics-outbound/doc.md

@@ -41,10 +41,13 @@ result in the batch.
 ## What is inspected
 
 Only responses with a JSON content type (`application/json` or any `+json` type
-such as `application/graphql-response+json`) are read, and bodies larger than
-`maxResponseBytes` (5 MiB by default) are skipped — by `Content-Length` when the
-header is present, or measured while reading when it is absent. Everything else
-passes through without the body being touched.
+such as `application/graphql-response+json`) are read. The policy reads up to
+`maxScanBytes` of the body (128 KiB by default, 5 MiB maximum) and scans it for
+the `errors` token; a response larger than that — by `Content-Length` when the
+header is present, or measured while reading when it is absent — is treated as
+error-free, so any errors it carries go unreported. Raise `maxScanBytes` if your
+GraphQL responses are larger. Everything else passes through without the body
+being touched.
 
 ## Logging
 
@@ -63,8 +66,9 @@ alert on it.
   `resolver`
 - `logErrors`: Also log a structured warning per errored response. **Default:**
   `false`
-- `maxResponseBytes`: Maximum response body size in bytes to inspect.
-  **Default:** `5242880` (5 MiB)
+- `maxScanBytes`: How many bytes of the response body to read and scan for the
+  `errors` token. A larger response is treated as error-free. Capped at 5 MiB.
+  **Default:** `131072` (128 KiB)
 
 ## Usage
 

package/docs/policies/graphql-analytics-outbound/schema.json

@@ -11,7 +11,7 @@
   "isHidden": false,
   "requiresAI": false,
   "products": ["api-gateway"],
-  "description": "Reports GraphQL errors returned in response bodies to Zuplo's GraphQL analytics. GraphQL servers following the standard Apollo / graphql-yoga pattern return `200 OK` with an `errors[]` array in the body when an operation fails, which HTTP-level analytics alone report as a success — add this policy to a GraphQL route and failed operations show up as failures on the GraphQL dashboard, classified by error type.\n\nEach error in `errors[]` is classified from its `extensions.code` following the Apollo Server conventions (`GRAPHQL_PARSE_FAILED` → `syntax`, `GRAPHQL_VALIDATION_FAILED` → `validation`, `UNAUTHENTICATED` / `FORBIDDEN` → `auth`, timeout codes → `timeout`); custom codes can be mapped with `errorCodeClassification`, and anything unrecognized falls back to `defaultErrorClass` (`resolver`). Optionally set `logErrors` to also write a structured warning per errored response. Bodies larger than `maxResponseBytes` (default 5 MiB) are not inspected.\n\nThe response always passes through unchanged — the body is read from a clone, and any internal failure is swallowed so reporting can never break the request. The route must be marked `x-graphql: true` in `routes.oas.json` (which enables GraphQL analytics for the route); without the marker the policy logs a warning and does nothing.",
+  "description": "Reports GraphQL errors returned in response bodies to Zuplo's GraphQL analytics. GraphQL servers following the standard Apollo / graphql-yoga pattern return `200 OK` with an `errors[]` array in the body when an operation fails, which HTTP-level analytics alone report as a success — add this policy to a GraphQL route and failed operations show up as failures on the GraphQL dashboard, classified by error type.\n\nEach error in `errors[]` is classified from its `extensions.code` following the Apollo Server conventions (`GRAPHQL_PARSE_FAILED` → `syntax`, `GRAPHQL_VALIDATION_FAILED` → `validation`, `UNAUTHENTICATED` / `FORBIDDEN` → `auth`, timeout codes → `timeout`); custom codes can be mapped with `errorCodeClassification`, and anything unrecognized falls back to `defaultErrorClass` (`resolver`). Optionally set `logErrors` to also write a structured warning per errored response. The policy reads up to `maxScanBytes` of the body (128 KiB by default, 5 MiB maximum), scanning it for the `errors` token; a response larger than that is treated as error-free. When the token is found and the body fits, it is parsed and its errors reported.\n\nThe response always passes through unchanged — the body is read from a clone, and any internal failure is swallowed so reporting can never break the request. The route must be marked `x-graphql: true` in `routes.oas.json` (which enables GraphQL analytics for the route); without the marker the policy logs a warning and does nothing.",
   "deprecatedMessage": "",
   "required": ["handler"],
   "properties": {
@@ -64,12 +64,13 @@
               "default": false,
               "description": "When `true`, also write a structured warning to the request log (message, `extensions.code`, and path of each error — capped at the first 10) whenever a response contains GraphQL errors."
             },
-            "maxResponseBytes": {
+            "maxScanBytes": {
               "type": "integer",
               "minimum": 1,
-              "default": 5242880,
+              "maximum": 5242880,
+              "default": 131072,
               "x-show-example": false,
-              "description": "Maximum response body size in bytes the policy will inspect. Larger bodies — by `Content-Length`, or measured while reading when the header is absent — pass through without being scanned, so their GraphQL errors (if any) go unreported. The default is 5 MiB."
+              "description": "How many bytes of the response body the policy reads to look for GraphQL errors. The body is read and scanned for the `errors` token up to this limit; a body larger than the limit — by `Content-Length`, or measured while reading when the header is absent — is treated as error-free, so any errors it carries go unreported. The default of 128 KiB suits the common case, where servers emit `errors` near the front of the body. Raise it (up to the 5 MiB maximum) to detect errors in larger responses, at the cost of reading more of every response. When the token is found and the body fits within the limit, the body is parsed and its errors are reported."
             }
           }
         }

package/docs/policies/graphql-cache-inbound/doc.md

@@ -0,0 +1,137 @@
+The GraphQL Cache policy stores successful GraphQL query responses in a
+[ZoneCache](https://zuplo.com/docs/articles/zonecache) and serves later,
+identical queries directly from the edge.
+
+### How caching works
+
+For every inbound request the policy:
+
+1. Reads the request body and parses it as GraphQL JSON
+   (`{ "query": "...", "variables": { ... }, "operationName": "..." }`).
+2. Parses the query and re-prints it, producing a canonical form that ignores
+   insignificant whitespace, field formatting, and fragment layout.
+3. Canonicalizes the `variables` by recursively sorting object keys.
+4. Hashes the normalized query, canonicalized variables, and `operationName`
+   (SHA-256) into a cache key. `operationName` is included because a document
+   with multiple operations returns a different response depending on which
+   operation the client selects.
+
+On a **hit**, the cached response is returned immediately. On a **miss**, the
+request is forwarded to the origin and a successful response is stored for
+future requests.
+
+Every response served or stored by the policy carries two headers:
+
+- **`x-cache`** — `HIT` when served from cache, `MISS` when fetched from the
+  origin.
+- **`x-cache-key`** — the first 8 characters of the cache key, useful for
+  confirming that two requests resolve to the same entry.
+
+Both headers are added to `access-control-expose-headers` so browsers can read
+them, without overwriting any value an upstream CORS policy already set.
+
+### What is and isn't cached
+
+- Only `query` operations are cached. **Mutations** and **subscriptions** are
+  forwarded to the origin and never cached. In a multi-operation document the
+  operation selected by `operationName` is the one that decides this.
+- **Malformed** GraphQL and **non-JSON** bodies are forwarded untouched so the
+  origin can return a proper error. Documents with multiple operations but no
+  `operationName` (or an `operationName` that matches none) are also forwarded.
+- Only `200` responses are cached, and only when the body is a successful
+  GraphQL result. Because GraphQL returns execution errors with a `200` status
+  and an `errors` array, responses carrying a non-empty `errors` array — and
+  non-JSON `200` bodies — are **not** cached.
+
+### Options
+
+- **`cacheName`** - The name of the cache used to store responses. Defaults to
+  `graphql-responses`. Routes that share a name share a cache; use distinct
+  names to isolate caches per route or per upstream.
+- **`ttlSeconds`** - How long, in seconds, a cached response is served before it
+  is considered stale and the next request is forwarded to the origin to refresh
+  the entry. Defaults to `60`.
+- **`cacheKeyHeaders`** - Request header names whose values are included in the
+  cache key (matched case-insensitively), and the control for how credentialed
+  requests are cached. See
+  [Authentication and per-user caching](#authentication-and-per-user-caching)
+  below. Defaults to omitted.
+
+### Authentication and per-user caching
+
+A response cache keyed only on the query would serve the first user's response
+to everyone. To prevent that, the policy **does not cache requests that carry an
+`authorization` or `cookie` header** by default — those requests are forwarded
+to the origin every time.
+
+To cache authenticated traffic safely, list the headers that make a response
+user-specific in `cacheKeyHeaders`. Each listed header's value becomes part of
+the cache key, so every distinct value (for example, every bearer token) gets
+its own cache entry:
+
+```json
+{
+  "name": "graphql-cache",
+  "policyType": "graphql-cache-inbound",
+  "handler": {
+    "export": "GraphQLCacheInboundPolicy",
+    "module": "$import(@zuplo/graphql)",
+    "options": {
+      "ttlSeconds": 30,
+      "cacheKeyHeaders": ["authorization"]
+    }
+  }
+}
+```
+
+If a request still carries an `authorization` or `cookie` header that is **not**
+in `cacheKeyHeaders`, it is left uncached — so partially configuring the
+allowlist fails safe rather than leaking across users.
+
+#### Caching credentialed requests as a single shared entry
+
+Sometimes a request must carry `authorization` (or `cookie`) to be authorized,
+but the response is identical for everyone allowed through — the credential
+gates access without changing the data. In that case, set `cacheKeyHeaders` to
+an **empty array** to cache one response and share it across all callers:
+
+```json
+{
+  "name": "graphql-cache",
+  "policyType": "graphql-cache-inbound",
+  "handler": {
+    "export": "GraphQLCacheInboundPolicy",
+    "module": "$import(@zuplo/graphql)",
+    "options": {
+      "cacheKeyHeaders": []
+    }
+  }
+}
+```
+
+This is distinct from omitting the option: omitting it keeps the safe default
+(credentialed requests are not cached), whereas `[]` is an explicit assertion
+that the response does not depend on the caller. **Only use `[]` when that is
+true** — otherwise one caller's response will be served to others.
+
+Response cookies are never shared. `Set-Cookie` (along with `Set-Cookie2` and
+`Clear-Site-Data`) is stripped from the stored entry, so a cookie an origin sets
+on one caller's response is never replayed to another from cache. The caller
+whose request reached the origin still receives the original `Set-Cookie`.
+
+### Example
+
+```json
+{
+  "name": "graphql-cache",
+  "policyType": "graphql-cache-inbound",
+  "handler": {
+    "export": "GraphQLCacheInboundPolicy",
+    "module": "$import(@zuplo/graphql)",
+    "options": {
+      "cacheName": "graphql-responses",
+      "ttlSeconds": 60
+    }
+  }
+}
+```

package/docs/policies/graphql-cache-inbound/intro.md

@@ -0,0 +1,15 @@
+This policy caches GraphQL query responses at the edge so identical queries are
+served without a round-trip to your origin.
+
+Unlike CDN caching that keys on the raw request body, this policy parses each
+GraphQL document and normalizes it before building a cache key. Insignificant
+whitespace, field formatting, and fragment layout are collapsed, and variable
+object keys are sorted. As a result, two requests that are semantically
+identical share a cache entry even when their bodies differ byte-for-byte — and
+there is no query size or nesting-depth limit.
+
+Only `query` operations are cached. Mutations, subscriptions, malformed
+documents, and non-GraphQL bodies are always forwarded to the origin untouched.
+To avoid serving one user's data to another, requests carrying an
+`authorization` or `cookie` header are not cached unless you opt in with the
+`cacheKeyHeaders` option.

package/docs/policies/graphql-cache-inbound/schema.json

@@ -0,0 +1,74 @@
+{
+  "$schema": "https://json-schema.org/draft-07/schema",
+  "$id": "https://cdn.zuplo.com/policies/graphql/schemas/graphql-cache-inbound.json",
+  "type": "object",
+  "title": "GraphQL Cache",
+  "isDeprecated": false,
+  "isPaidAddOn": false,
+  "isEnterprise": false,
+  "isInternal": false,
+  "isBeta": false,
+  "isHidden": false,
+  "requiresAI": false,
+  "products": ["api-gateway"],
+  "description": "Caches GraphQL query responses at the edge so identical queries are served without a round-trip to the origin.\n\nUnlike CDN caching that keys on the raw request body, this policy parses the GraphQL document and normalizes it before hashing: insignificant whitespace, field formatting, and fragment layout are collapsed, and variable object keys are sorted. Two requests that are semantically identical therefore share a cache entry even when their bodies differ byte-for-byte. There is no query size or nesting-depth limit.\n\nOnly `query` operations are cached. Mutations, subscriptions, malformed documents, and non-JSON bodies are forwarded to the origin untouched. Cache hits and misses are reported on the `x-cache` response header, with a short key fingerprint on `x-cache-key`.\n\nTo avoid serving one user's data to another, requests carrying an `authorization` or `cookie` header are not cached by default. Use `cacheKeyHeaders` to opt into caching them: each listed header's value is included in the cache key, so distinct credentials get distinct cache entries.",
+  "deprecatedMessage": "",
+  "required": ["handler"],
+  "properties": {
+    "handler": {
+      "type": "object",
+      "default": {},
+      "required": ["export", "module", "options"],
+      "properties": {
+        "export": {
+          "const": "GraphQLCacheInboundPolicy",
+          "description": "The name of the exported type"
+        },
+        "module": {
+          "const": "$import(@zuplo/graphql)",
+          "description": "The module containing the policy"
+        },
+        "options": {
+          "title": "GraphQLCacheInboundPolicyOptions",
+          "type": "object",
+          "description": "The options for this policy.",
+          "required": [],
+          "additionalProperties": false,
+          "properties": {
+            "cacheName": {
+              "type": "string",
+              "default": "graphql-responses",
+              "examples": ["graphql-responses"],
+              "description": "The name of the cache used to store responses. Routes that share a name share a cache; use distinct names to isolate caches per route or per upstream."
+            },
+            "ttlSeconds": {
+              "type": "number",
+              "default": 60,
+              "examples": [60],
+              "description": "How long, in seconds, a cached response is served before it is considered stale and the next request is forwarded to the origin to refresh the entry."
+            },
+            "cacheKeyHeaders": {
+              "type": "array",
+              "items": {
+                "type": "string"
+              },
+              "examples": [["authorization"]],
+              "description": "Request header names whose values are included in the cache key (matched case-insensitively), and the control for how credentialed requests are cached. Omit this option (the default) and requests carrying an `authorization` or `cookie` header are not cached, to avoid serving one user's response to another. List those headers to cache such requests keyed per value, so each distinct value gets its own entry (a credential header you don't list still blocks caching, so a partial list fails safe). Set it to an empty array `[]` to cache a single response shared across all callers — only do this when the response does not depend on who is calling, as it disables the per-user safety check."
+            }
+          }
+        }
+      },
+      "examples": [
+        {
+          "export": "GraphQLCacheInboundPolicy",
+          "module": "$import(@zuplo/graphql)",
+          "options": {
+            "cacheKeyHeaders": ["authorization"],
+            "cacheName": "graphql-responses",
+            "ttlSeconds": 60
+          }
+        }
+      ]
+    }
+  }
+}