zuplo 6.72.3 → 6.72.7

package/docs/analytics/access-and-entitlements.md

@@ -7,56 +7,49 @@ sidebar_label: "Access & Entitlements"
 
 - Confirm whether your account can see analytics.
 - Find out how many days of history you have access to.
-- Understand the trial banner or the demo mode link.
+- Understand the trial banner.
 
-## Plan requirements
+## Availability
 
-Analytics must be enabled on your account. Without it, the Analytics page shows
-an upsell view with a **Contact Sales** call-to-action and no charts.
+Analytics is included on every plan. Your plan determines how much history you
+can query — see [Data retention](#data-retention). If the Analytics page shows
+an upsell view with a **Contact Sales** call-to-action instead of charts, your
+account has analytics disabled — contact your Zuplo account team.
 
 ## Free trial
 
-New accounts with analytics enabled get an automatic free trial. The trial:
+Every new account gets an automatic 14-day observability trial. During the
+trial:
 
-- Runs for the same number of days as your account's retention window.
-- Shows a banner across the top of the Analytics page: "You're on a {N}-day
-  preview of Analytics, {N} days left."
-- Includes two call-to-actions: **View demo →** (loads the dashboard with sample
-  data) and **Contact sales**.
+- You get longer history windows for analytics, logs, and traces than your plan
+  includes. Accounts on self-serve plans get the Builder/Business windows (7
+  days of analytics, 1 day of logs and traces); Enterprise trial accounts get
+  the Enterprise windows. See [Data retention](#data-retention).
+- A banner appears across the top of the Observability tabs: "You're on a 14-day
+  trial of Zuplo Observability — {N} days left", with a **Contact sales** link.
 
-Accounts on the legacy analytics version are not eligible for the trial. They
-continue to use the previous experience.
+When the trial ends, your plan's own history windows apply.
 
-:::note
-
-The trial banner notes that the charts may look sparse if your account hasn't
-yet generated much traffic. Use **View demo →** to see what a fully populated
-dashboard looks like.
+## Data retention
 
-:::
+Each account has history windows for analytics, logs, and traces. The windows
+depend on your plan:
 
-## Data retention
+| Plan               | Analytics history | Log & trace history |
+| ------------------ | ----------------- | ------------------- |
+| Free               | 1 day             | Live (15 minutes)   |
+| Builder / Business | 7 days            | 1 day               |
+| Enterprise         | 30 days           | 3 days              |
 
-Each account has an analytics history window measured in days. The window
-controls:
+The analytics window controls:
 
 - How far back you can scroll using the time-range picker.
 - Which presets in the picker are available. Presets longer than your window are
-  locked with an **Upgrade for [preset]** tooltip.
+  locked and show an **Upgrade** badge; hover one for details.
 - The maximum start and end values when you pick a custom range.
 
-If you need a longer window, contact your Zuplo account team.
-
-## Demo mode
-
-Append `?demo=true` to the Analytics URL, or click **View demo →** in the trial
-banner, to switch into demo mode. In demo mode:
-
-- Charts and tables are populated with synthetic sample data.
-- A persistent banner reads: "You're viewing the Analytics demo with sample
-  data. Your real analytics aren't shown here."
-
-Remove the `demo` parameter from the URL to return to your real data.
+If you need a longer window, contact your Zuplo account team — custom retention
+is available on Enterprise plans.
 
 ## Scope: account vs project
 

package/docs/analytics/overview.md

@@ -32,7 +32,7 @@ Analytics lives in the **Observability** tab of the Zuplo Portal, alongside
 ## What's in this section
 
 - [Access and entitlements](./access-and-entitlements.md): plans, free trial,
-  demo mode, retention.
+  retention.
 - [Shared controls](./shared-controls.md): time range, filters, environment
   selector, banners, URL state.
 - Sections:
@@ -56,12 +56,13 @@ You'll see a subset of sections depending on your plan and project setup:
 
 | Section   | When it appears                                            |
 | --------- | ---------------------------------------------------------- |
-| Requests  | All accounts with analytics enabled.                       |
+| Requests  | All accounts.                                              |
 | Origins   | The project uses managed-edge origins.                     |
-| Consumers | All accounts with analytics enabled.                       |
-| Agents    | All accounts with analytics enabled.                       |
+| Consumers | All accounts.                                              |
+| Agents    | All accounts.                                              |
 | MCP       | The project type is **standard** and the project uses MCP. |
 | GraphQL   | The project proxies a GraphQL API.                         |
 
-If you don't see Analytics at all, your account likely doesn't have analytics
-enabled. See [Access and entitlements](./access-and-entitlements.md).
+Analytics is included on every plan. If you don't see Analytics at all, your
+account may have it disabled — see
+[Access and entitlements](./access-and-entitlements.md).

package/docs/analytics/reference/url-parameters.md

@@ -8,7 +8,7 @@ view.
 
 ## When to use this
 
-- Build a permalink to a specific time window, filter set, or demo view.
+- Build a permalink to a specific time window or filter set.
 - Embed an Analytics link in a runbook, postmortem, or dashboard.
 - Understand what each query parameter does.
 
@@ -16,11 +16,9 @@ view.
 
 | Parameter      | Example                                                | Effect                                                                                    |
 | -------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------- |
-| `time`         | `?time=7d`                                             | Apply a preset. Values: `1h`, `6h`, `24h`, `3d`, `7d`, `14d`, `28d`, `60d`, `90d`.        |
+| `time`         | `?time=7d`                                             | Apply a preset. Values: `1h`, `6h`, `24h`, `3d`, `7d`, `14d`, `28d`, `30d`, `60d`, `90d`. |
 | `start`, `end` | `?start=2026-05-01T00:00:00Z&end=2026-05-15T00:00:00Z` | Custom range as ISO-8601 datetimes. Overrides `time` when both are present.               |
 | `filter`       | `?filter=httpStatus:class:5xx`                         | Add a filter as `<field>:<matchmode>:<value>`. Repeat the parameter for multiple filters. |
-| `demo`         | `?demo=true`                                           | Demo mode (sample data instead of your real analytics).                                   |
-| `preview`      | `?preview=1`                                           | Legacy preview mode.                                                                      |
 
 ## Match modes for `filter`
 
@@ -48,12 +46,6 @@ Custom range with two filters:
 ?start=2026-05-01T00:00:00Z&end=2026-05-08T00:00:00Z&filter=country:equals:US&filter=httpMethod:equals:POST
 ```
 
-Open the demo:
-
-```
-?demo=true
-```
-
 ## Sharing
 
 The recipient sees the same view, provided they have access to the project or

package/docs/analytics/shared-controls.md

@@ -18,7 +18,7 @@ State persists to the URL so you can share or bookmark any view.
 The time range picker controls every chart, table, and KPI in the active
 section.
 
-**Presets.** Last 1h, 6h, 24h, 3d, 7d, 14d, 28d, 60d, 90d.
+**Presets.** Last 1h, 6h, 24h, 3d, 7d, 14d, 28d, 30d, 60d, 90d.
 
 **Custom range.** Use the datetime-local inputs for **Start** and **End**. Both
 fields are clamped to your account's retention window.
@@ -80,8 +80,6 @@ There's no separate share button.
 | `time`         | `?time=7d`                                             | Apply a preset.                                         |
 | `start`, `end` | `?start=2026-05-01T00:00:00Z&end=2026-05-15T00:00:00Z` | Custom range. Overrides `time`.                         |
 | `filter`       | `?filter=httpStatus:class:5xx`                         | Add a filter. Repeat the parameter for multiple values. |
-| `demo`         | `?demo=true`                                           | Demo mode (sample data).                                |
-| `preview`      | `?preview=1`                                           | Legacy preview mode.                                    |
 
 See [URL parameters](./reference/url-parameters.md) for the full reference.
 
@@ -94,13 +92,8 @@ a refetch.
 
 ## Banners
 
-Banners appear at the top of the page in this priority order:
-
-1. **Preview banner**: when `preview=1` is set. Indicates legacy preview mode.
-2. **Demo banner**: when `demo=true` is set. Reminds you sample data is shown
-   instead of your real analytics.
-3. **Trial banner**: for new accounts with analytics. Shows days remaining and
-   offers **View demo →** and **Contact Sales**.
+During the 14-day observability trial, a banner appears at the top of the page
+showing the days remaining, with a **Contact sales** link.
 
 ## Loading and empty states
 

package/docs/analytics/tabs/agents.md

@@ -74,9 +74,9 @@ The filter bar applies. `originHost` is not applicable here. See
 ## Troubleshooting
 
 **The Agents section is empty.** Either no classified agents called your gateway
-in the window, or your retention window doesn't yet include any agent traffic.
-Try the demo with **View demo →** in the trial banner to see what a populated
-view looks like. See [Access and entitlements](../access-and-entitlements.md).
+in the window, or your
+[retention window](../access-and-entitlements.md#data-retention) doesn't yet
+include any agent traffic.
 
 **I see a known agent in my logs but not here.** The classifier is conservative;
 it labels traffic that clearly matches a known agent fingerprint. Generic SDK

package/docs/analytics/tabs/requests.md

@@ -91,7 +91,5 @@ not include any geolocated requests.
 that breakdown. Top-10 plus 50 covers up to 60 distinct values; beyond that,
 narrow the time range or add a filter.
 
-**My charts look sparse.** If your account is new, the trial banner across the
-top calls this out. Click **View demo →** in the banner to see what a fully
-populated dashboard looks like. See
-[Access and entitlements](../access-and-entitlements.md).
+**My charts look sparse.** New accounts may not have generated much traffic yet.
+Charts fill in as requests flow through your gateway.

package/docs/articles/connect-to-aws-alb-with-mtls.mdx

@@ -20,9 +20,9 @@ present an X.509 certificate that chains to a Certificate Authority (CA) in the
 ALB's trust store. Zuplo presents that client certificate on each outbound
 request, and the ALB rejects anything that can't.
 
-This guide covers the Zuplo side of that connection: uploading a client
-certificate and presenting it on requests to the ALB. It does **not** cover
-configuring the ALB itself — for that, follow the AWS documentation linked in
+This guide covers uploading a client certificate to Zuplo and presenting it on
+requests to the ALB. It does **not** cover configuring the ALB itself — for
+that, follow the AWS documentation linked in
 [Configure the ALB](#1-configure-the-alb).
 
 ## How it works
@@ -64,10 +64,13 @@ For background on the gateway-to-origin direction in general, see
 
 Before you begin, you need:
 
-- A client certificate and private key (PEM-encoded) issued by a CA. The same CA
-  must be uploaded to the ALB's trust store.
+- A PEM-encoded client certificate (`client-cert.pem`), matching private key
+  (`client-key.pem`), and public CA certificate or bundle (`client-ca.pem`). The
+  same CA must be in the ALB's trust store.
 - An AWS Application Load Balancer with an HTTPS listener you can configure for
   mTLS.
+- The AWS CLI installed and authenticated with permission to inspect the ALB's
+  listener and trust store.
 - The [Zuplo CLI](../cli/overview.mdx) installed and authenticated.
 
 ## 1/ Configure the ALB
@@ -93,7 +96,79 @@ edge.
 
 :::
 
-## 2/ Upload your client certificate to Zuplo
+## 2/ Validate the certificate and ALB trust
+
+Confirm that the listener uses verify mode and capture its trust store ARN:
+
+```bash
+aws elbv2 describe-listeners \
+  --listener-arns <HTTPS_LISTENER_ARN> \
+  --query 'Listeners[0].MutualAuthentication' \
+  --output json
+
+TRUST_STORE_ARN=$(aws elbv2 describe-listeners \
+  --listener-arns <HTTPS_LISTENER_ARN> \
+  --query 'Listeners[0].MutualAuthentication.TrustStoreArn' \
+  --output text)
+
+aws elbv2 describe-trust-stores \
+  --trust-store-arns "$TRUST_STORE_ARN" \
+  --query 'TrustStores[0].{Name:Name,Status:Status,CACertificates:NumberOfCaCertificates}' \
+  --output table
+```
+
+The listener mode should be `verify`, and the trust store status should be
+`ACTIVE`.
+
+Inspect the client certificate and verify its path against the CA certificate:
+
+```bash
+openssl x509 \
+  -in client-cert.pem \
+  -noout \
+  -subject \
+  -issuer \
+  -dates \
+  -purpose
+
+openssl verify \
+  -verbose \
+  -purpose sslclient \
+  -x509_strict \
+  -show_chain \
+  -CAfile client-ca.pem \
+  client-cert.pem
+```
+
+`SSL client` should report `Yes`, and verification should return
+`client-cert.pem: OK`. Also confirm that the certificate and private key match:
+
+```bash
+CERT_KEY_HASH=$(openssl x509 -in client-cert.pem -noout -pubkey | openssl sha256)
+PRIVATE_KEY_HASH=$(openssl pkey -in client-key.pem -pubout | openssl sha256)
+
+test "$CERT_KEY_HASH" = "$PRIVATE_KEY_HASH" &&
+  echo "Certificate and private key match" ||
+  echo "ERROR: Certificate and private key do not match"
+```
+
+For the strongest offline check, run `openssl verify` with the exact CA bundle
+uploaded to the ALB trust store instead of `client-ca.pem`.
+
+If the ALB is reachable, test the TLS handshake directly:
+
+```bash
+curl --verbose \
+  --cert client-cert.pem \
+  --key client-key.pem \
+  "https://<ALB_HOSTNAME>/<TEST_PATH>"
+```
+
+Use a hostname covered by the ALB's server certificate. Any HTTP response,
+including a `401`, `403`, or `404`, shows that the TLS handshake completed; a
+client certificate failure occurs before an HTTP response is produced.
+
+## 3/ Upload your client certificate to Zuplo
 
 Use the Zuplo CLI to upload the client certificate and private key to your
 project. The CA that issued this certificate must already be in the ALB's trust
@@ -119,7 +194,7 @@ when you create the certificate.
 
 :::
 
-## 3/ Present the certificate on requests to the ALB
+## 4/ Present the certificate on requests to the ALB
 
 Reference the uploaded certificate by name when the gateway forwards requests to
 the ALB. Use the ALB's DNS name (or a custom domain pointed at it) as the
@@ -162,7 +237,7 @@ export default async function (request: ZuploRequest, context: ZuploContext) {
 }
 ```
 
-## 4/ Use environment variables across environments
+## 5/ Use environment variables across environments
 
 To use a different certificate per environment, store the certificate name in an
 [environment variable](./environment-variables.mdx) and reference it with the
@@ -226,11 +301,12 @@ received — usually a TLS handshake problem. Confirm that:
 
 ### The ALB rejects the certificate
 
-If the handshake completes but the ALB returns a `403`, the certificate is being
-presented but not trusted. Re-check the ALB trust store and confirm the listener
-is in **verify** mode, not passthrough. If your client certificate is issued by
-an intermediate CA, make sure the trust store contains the full chain back to
-the root.
+If the TLS handshake fails, re-check the ALB trust store and confirm the
+listener is in **verify** mode, not passthrough. If your client certificate is
+issued by an intermediate CA, make sure the trust store contains the CA chain
+required to validate the certificate. ALB connection logs can identify errors
+such as `ClientCertUntrusted`, `ClientCertPurposeInvalid`, `ClientCertExpired`,
+or `ClientCertNotYetValid`.
 
 ### No certificate appears to be sent
 

package/docs/articles/graphql-security.mdx

@@ -180,7 +180,8 @@ outbound filter policy goes in the `outbound` array:
 ## Example repository
 
 For a complete, runnable setup, see the
-[GraphQL API with Zuplo example repository](https://github.com/zuplo/zuplo-graphql-example).
+[GraphQL API with Zuplo example repository](https://github.com/zuplo-samples/graphql).
+You can [deploy it to your own account in one click](./graphql.mdx).
 
 ## Next steps
 

package/docs/articles/graphql.mdx

@@ -12,6 +12,14 @@ Zuplo has rich support for GraphQL. Pass your requests through the gateway,
 attach policies, track operations with analytics, and publish documentation for
 your schema in the Dev Portal. This guide walks you through setting it up.
 
+<ZupIt repoUrl="https://github.com/zuplo-samples/graphql">
+
+Want to see it working first? This example proxies a public GraphQL API with
+edge caching, query depth limiting, and analytics already wired up — deploy it
+to your own Zuplo account in one click.
+
+</ZupIt>
+
 :::tip{title="TL;DR"}
 
 - [ ] Proxy your GraphQL endpoint through a POST `/graphql` route with the URL

package/docs/articles/opentelemetry.mdx

@@ -7,10 +7,9 @@ Zuplo ships with an OpenTelemetry plugin (`@zuplo/otel`) that instruments your
 API and exports traces and logs in OpenTelemetry format. The quickest way to use
 it is Zuplo's built-in tracing: add the plugin and your traces are stored by
 Zuplo and shown in the portal's **Observability** tab, with no collector to run
-or backend to host. You can also export to your own OpenTelemetry backend, or to
-both at once.
-
-<EnterpriseFeature name="OpenTelemetry" />
+or backend to host. Built-in tracing is available on every plan. You can also
+export to your own OpenTelemetry backend (an Enterprise feature), or to both at
+once.
 
 ## Tracing
 
@@ -68,7 +67,8 @@ Deploy your project and open the **Observability** tab to see traces.
 Each trace is tagged with the account, project, deployment, and environment it
 ran in, plus the request ID (the `zp-rid` value) that also appears on your
 [logs](#logging), so you can move between a request's logs and its trace. How
-long traces are kept depends on your plan.
+long traces are kept depends on your plan — see
+[data retention](../analytics/access-and-entitlements.md#data-retention).
 
 :::note
 
@@ -81,6 +81,8 @@ still run.
 
 ### Export to Your Own Backend
 
+<EnterpriseFeature name="Exporting to your own OpenTelemetry backend" />
+
 To send traces to an OpenTelemetry service such as
 [Honeycomb](https://honeycomb.io), [Middleware](https://middleware.io/),
 [Dynatrace](https://dynatrace.com), [Jaeger](https://www.jaegertracing.io/), or

package/docs/articles/securing-backend-mtls.mdx

@@ -30,11 +30,38 @@ gateways, and Zuplo can verify it's connecting to the correct backend service.
 
 Before you begin, you need:
 
-- A client certificate and private key generated from a Certificate Authority
-  (CA) that your backend trusts
+- A PEM-encoded client certificate and matching private key generated from a
+  Certificate Authority (CA) that your backend trusts
 - Your backend service configured to require and validate client certificates
 - The Zuplo CLI installed (see [CLI documentation](../cli/overview.mdx))
 
+## Client certificate requirements
+
+The certificate uploaded to Zuplo is the client, or leaf, certificate that the
+gateway presents to your backend. It should have the following properties:
+
+- X.509 version 3
+- `Basic Constraints: critical, CA:FALSE`
+- `Key Usage: critical, Digital Signature`
+- `Extended Key Usage: TLS Web Client Authentication` (`clientAuth`)
+- An RSA key between 2048 and 8192 bits, or an ECDSA key using P-256, P-384, or
+  P-521
+- A SHA-256 or stronger signature
+- A subject that uniquely identifies the gateway credential
+- A validity period appropriate for your certificate rotation policy
+
+The issuing CA certificate must be X.509 version 3 with
+`Basic Constraints: critical, CA:TRUE` and a key usage that includes
+`Certificate Sign` and `CRL Sign`. Your backend's trust store must contain the
+CA certificates needed to build a path from the client certificate to a trusted
+root. When the trusted CA directly signs the client certificate, you do not need
+a client certificate-chain bundle. If an intermediate CA signs it, follow your
+backend's requirements for presenting and trusting the intermediate chain.
+
+The private key must match the public key in the client certificate. Keep it
+secret and limit access to it. The key must be unencrypted when uploaded to
+Zuplo so the gateway can use it without a passphrase.
+
 ## 1/ Upload Your Certificate
 
 Use the Zuplo CLI to upload your client certificate and private key to your
@@ -229,10 +256,72 @@ For local development, consider:
 
 ### Certificate Validation Errors
 
-If your backend rejects the certificate, verify:
+Inspect the certificate and confirm its subject, issuer, validity, and client
+authentication purpose:
+
+```bash
+openssl x509 \
+  -in client.crt \
+  -noout \
+  -subject \
+  -issuer \
+  -serial \
+  -dates \
+  -purpose
+```
+
+`SSL client` should report `Yes`. To inspect all extensions, run
+`openssl x509 -in client.crt -noout -text` and confirm the certificate reports
+`CA:FALSE`, `Digital Signature`, and `TLS Web Client Authentication`.
+
+Check that the certificate will remain valid for at least seven days:
+
+```bash
+openssl x509 -in client.crt -noout -checkend 604800
+```
+
+Validate the certificate path against the same CA bundle your backend trusts:
+
+```bash
+openssl verify \
+  -verbose \
+  -purpose sslclient \
+  -x509_strict \
+  -show_chain \
+  -CAfile backend-client-ca-bundle.pem \
+  client.crt
+```
+
+The expected result is `client.crt: OK`. Common errors include:
+
+- `unable to get local issuer certificate`: The issuing CA or an intermediate CA
+  is missing from the backend's trust bundle.
+- `unsupported certificate purpose`: The client certificate is missing the
+  `clientAuth` extended key usage.
+- `certificate has expired`: The client certificate is outside its validity
+  period.
+- `invalid CA certificate`: An issuing certificate is missing valid CA
+  extensions.
+- `key usage does not include certificate signing`: An issuing CA does not have
+  the `keyCertSign` key usage.
+
+Confirm that the certificate and private key contain the same public key:
+
+```bash
+CERT_KEY_HASH=$(openssl x509 -in client.crt -noout -pubkey | openssl sha256)
+PRIVATE_KEY_HASH=$(openssl pkey -in client.key -pubout | openssl sha256)
+
+test "$CERT_KEY_HASH" = "$PRIVATE_KEY_HASH" &&
+  echo "Certificate and private key match" ||
+  echo "ERROR: Certificate and private key do not match"
+```
+
+If your backend still rejects the certificate, verify:
 
 - The certificate is signed by a CA that your backend trusts
 - The certificate hasn't expired
+- The certificate has the required key usage and extended key usage
+- The certificate and private key match
 - The certificate name in your code matches the uploaded certificate name
 
 ### Connection Failures

package/docs/articles/troubleshooting-slow-responses.mdx

@@ -240,9 +240,10 @@ For the most detailed view of where time is spent in your request pipeline,
 enable [OpenTelemetry tracing](./opentelemetry.mdx). The OpenTelemetry plugin
 automatically instruments your API and provides span-level timing for each stage
 of the request lifecycle — including inbound policies, the handler, outbound
-policies, and any subrequests made via `fetch` in custom code.
-
-<EnterpriseFeature name="OpenTelemetry" />
+policies, and any subrequests made via `fetch` in custom code. Built-in tracing
+is available on every plan; see
+[data retention](../analytics/access-and-entitlements.md#data-retention) for how
+much trace history you can query.
 
 With tracing enabled, you can see exactly how long each policy and handler takes
 to execute, making it straightforward to identify which component is adding

package/docs/articles/troubleshooting.md

@@ -179,7 +179,9 @@ const response = await fetch("https://api.example.com/data", {
 The Zuplo Portal provides real-time log viewing for deployed environments. Open
 the **Observability** tab in your project — the **Logs** view opens by default —
 then use the **Environment** filter to select the deployed environment and see
-live request logs and any messages logged with `context.log`.
+live request logs and any messages logged with `context.log`. How far back you
+can search depends on your plan — see
+[Access and entitlements](../analytics/access-and-entitlements.md#data-retention).
 
 ### Using context.log
 

package/docs/policies/_index.md

@@ -104,6 +104,8 @@
 | traffic-splitting-inbound | Traffic Splitting | Splits traffic randomly across a set of weighted base paths. On each request one base path is selected (weighted by `weight`) and written to the request custom context at `customOutputProperty`. Reference it from a later URL Rewrite `rewritePattern` or URL Forward `baseUrl`, e.g. `${context.custom.trafficSplitting.basePath}`. | api-gateway |
 | transform-body-inbound | Transform Request Body | Transform the body of an incoming request. | api-gateway |
 | transform-body-outbound | Transform Response Body | Transform the body of an outgoing response. | api-gateway |
+| upstream-aws-federated-auth-inbound | Upstream AWS Federated Auth | Resolves AWS credentials with STS AssumeRoleWithWebIdentity using Zuplo's ambient OIDC identity — no AWS keys are stored anywhere. The role's trust policy must trust the Zuplo OIDC identity provider. Resolved credentials are registered on the request context for the AWS Lambda handler and custom code to sign upstream requests with `AwsClient.fromContext`. This policy does not itself sign or forward the request. | api-gateway |
+| upstream-aws-service-auth-inbound | Upstream AWS Service Auth | Resolves AWS credentials from static access keys (optionally exchanged for an IAM role's temporary credentials via STS AssumeRole) and registers them on the request context. The AWS Lambda handler and custom code read them with `AwsClient.fromContext` to sign upstream requests. This policy does not itself sign or forward the request. | api-gateway |
 | upstream-azure-ad-service-auth-inbound | Upstream Azure AD Service Auth | Uses Azure Active Directory to add an Authorization header to the request in order to authenticate requests using Azure identity. | api-gateway |
 | upstream-firebase-admin-auth-inbound | Upstream Firebase Admin Auth | Creates a Firebase Admin token and attaches it to the outgoing request. Useful when calling Firebase services as an administrator. | api-gateway |
 | upstream-firebase-user-auth-inbound | Upstream Firebase User Auth | Creates a Firebase custom user token and attaches it to the outgoing request. Useful when calling Firebase services as user. | api-gateway |

package/docs/policies/clerk-jwt-auth-inbound/schema.json

@@ -42,8 +42,8 @@
             },
             "frontendApiUrl": {
               "type": "string",
-              "examples": ["https://sensible-skunk-49.clerk.accounts.dev"],
-              "description": "Your Clerk frontend api url, i.e. `https://sensible-skunk-49.clerk.accounts.dev`. Can be found in the Clerk portal: https://dashboard.clerk.com/last-active?path=api-keys."
+              "examples": ["https://verb-noun-00.clerk.accounts.dev"],
+              "description": "Your Clerk Frontend API URL, i.e. `https://verb-noun-00.clerk.accounts.dev`. Can be found in the Clerk portal: https://dashboard.clerk.com/last-active?path=api-keys."
             },
             "oAuthResourceMetadataEnabled": {
               "type": "boolean",
@@ -59,7 +59,7 @@
           "module": "$import(@zuplo/runtime)",
           "options": {
             "allowUnauthenticatedRequests": false,
-            "frontendApiUrl": "https://sensible-skunk-49.clerk.accounts.dev",
+            "frontendApiUrl": "https://verb-noun-00.clerk.accounts.dev",
             "oAuthResourceMetadataEnabled": false
           }
         }

package/docs/policies/mcp-auth0-oauth-inbound/schema.json

@@ -100,7 +100,7 @@
                 {
                   "type": "object",
                   "additionalProperties": false,
-                  "required": ["enabled", "trustedIssuers"],
+                  "required": ["enabled"],
                   "properties": {
                     "enabled": {
                       "const": true,
@@ -109,21 +109,24 @@
                     "trustedIssuers": {
                       "type": "array",
                       "minItems": 1,
-                      "description": "Trusted ID-JAG issuers. These values are never published in OAuth metadata.",
+                      "description": "Trusted ID-JAG issuers. These values are never published in OAuth metadata. Omit to trust this policy's browser-login IdP.",
                       "items": {
                         "type": "object",
                         "additionalProperties": false,
-                        "required": ["issuer", "jwksUrl"],
+                        "dependentRequired": {
+                          "issuer": ["jwksUrl"],
+                          "jwksUrl": ["issuer"]
+                        },
                         "properties": {
                           "issuer": {
                             "type": "string",
                             "format": "uri",
-                            "description": "Exact issuer URL expected in the ID-JAG iss claim."
+                            "description": "Exact issuer URL expected in the ID-JAG iss claim. Provide together with jwksUrl, or omit both to default to this policy's browser-login IdP."
                           },
                           "jwksUrl": {
                             "type": "string",
                             "format": "uri",
-                            "description": "JWKS URL used to verify ID-JAG signatures from this issuer."
+                            "description": "JWKS URL used to verify ID-JAG signatures from this issuer. Provide together with issuer, or omit both to default to this policy's browser-login IdP."
                           },
                           "expectedClientIds": {
                             "type": "array",