zuplo 6.70.71 → 6.71.1

package/docs/articles/graphql.mdx

@@ -8,29 +8,27 @@ tags:
   - backends
 ---
 
-Zuplo fronts GraphQL APIs the same way it fronts REST: requests pass through a
-gateway route — with whatever authentication, rate limiting, and
-GraphQL-specific policies you attach — and your Dev Portal documents the schema.
-This guide covers both halves: adding a GraphQL endpoint to your gateway routes,
-then rendering a schema reference and playground in the Dev Portal with
-`@zudoku/plugin-graphql`.
-
-## Prerequisites
-
-- A Zuplo project
-- An upstream GraphQL API to proxy
-- For the Dev Portal section: your project's
-  [Dev Portal](../dev-portal/introduction.mdx) lives in its `docs/` folder. The
-  plugin requires the `zudoku` package version `0.80.1` or newer — check the
-  version in `docs/package.json` and
-  [update the Dev Portal](../dev-portal/updating.mdx) if yours is older.
+Zuplo fronts a GraphQL API like any other backend: requests pass through a
+gateway route with the policies you attach, and your Dev Portal documents the
+schema. This guide proxies the endpoint, reports failed operations to analytics,
+and publishes a schema reference and playground.
+
+:::tip{title="TL;DR"}
+
+- [ ] Proxy your GraphQL endpoint through a route with the URL Rewrite handler
+- [ ] Tag the route with the `x-graphql` extension so the Portal recognizes it
+- [ ] Surface failed operations with the `graphql-analytics-outbound` policy
+- [ ] Publish a schema reference and playground with the `graphqlPlugin` for the
+      Developer Portal
+
+:::
 
 ## Add a GraphQL endpoint to your gateway
 
-A GraphQL API serves every query and mutation from a single endpoint, so the
-gateway route uses the [URL Rewrite handler](../handlers/url-rewrite.mdx) —
-every request goes to exactly the upstream URL — rather than URL Forward, which
-appends the incoming path.
+Because GraphQL uses a single endpoint, the route uses the
+[URL Rewrite handler](../handlers/url-rewrite.mdx) — every request goes to
+exactly the upstream URL — rather than URL Forward, which appends the incoming
+path.
 
 ### Add a new GraphQL route
 
@@ -45,10 +43,11 @@ appends the incoming path.
 2. **Add the endpoint**
 
    Click **Add** and select **GraphQL Endpoint**. This creates a `POST /graphql`
-   route preconfigured with the URL Rewrite handler and a demo upstream. If
-   `/graphql` is already taken, the Portal appends a short suffix (for example
-   `/graphql-b891`) — edit the path to whatever you prefer. GraphQL routes show
-   a **GraphQL** badge in the route list instead of an HTTP method.
+   route preconfigured with the URL Rewrite handler, a demo upstream, and the
+   [GraphQL Analytics policy](#report-failed-operations-to-analytics) for error
+   reporting. If `/graphql` is already taken, the Portal appends a short suffix
+   (for example `/graphql-b891`) — edit the path to whatever you prefer. GraphQL
+   routes show a **GraphQL** badge in the route list instead of an HTTP method.
 
 3. **Point it at your upstream**
 
@@ -106,65 +105,103 @@ set:
 
 :::tip{title="Secure the endpoint"}
 
-GraphQL has its own attack surface — deeply nested queries, expensive
-operations, and schema introspection. Zuplo ships policies for all three. See
+Zuplo ships policies for query depth, complexity, and introspection. See
 [Secure your GraphQL API](./graphql-security.mdx) to add complexity limits and
 disable introspection in production.
 
 :::
 
-## Document the API in your Dev Portal
+## Report failed operations to analytics
+
+Failed GraphQL operations return `200 OK` with an `errors[]` array in the body
+(the Apollo Server and graphql-yoga convention). HTTP-level analytics read that
+`200` as a success, so those failures never show up on the
+[GraphQL analytics dashboard](../analytics/tabs/graphql.md).
 
-The `@zudoku/plugin-graphql` package renders GraphQL APIs in your Dev Portal
-from a schema. Each plugin instance produces a browsable type reference
-(queries, mutations, objects, enums, and so on) plus a playground, generated
-straight from your schema.
+The **GraphQL Analytics** policy closes that gap. It reads each response body,
+counts the GraphQL errors, and classifies every one by its `extensions.code` —
+`syntax`, `validation`, `auth`, `timeout`, or `resolver` — so failed operations
+appear on the dashboard as failures, broken down by error class. The response
+passes through to the client unchanged.
 
 :::caution{title="Beta"}
 
-The GraphQL plugin is in beta. During the beta it isn't available in your
-project's working copy — it only works in projects
-[connected to source control](./source-control.mdx).
+The GraphQL Analytics policy is in beta. You can use it today, but it may change
+in non-backward compatible ways before the final release.
 
 :::
 
-<Stepper>
+New GraphQL endpoints include this policy automatically — the
+[Add a new GraphQL route](#add-a-new-graphql-route) flow attaches a
+`graphql-analytics-outbound` policy to the route's `outbound` chain, so error
+reporting works out of the box. If you instead
+[marked an existing route as GraphQL](#mark-an-existing-route-as-graphql), add a
+`graphql-analytics-outbound` policy and reference it in that route's `outbound`
+list.
 
-1. **Install the plugin**
+Tune the policy by editing its `options` in `config/policies.json`. Out of the
+box it classifies the standard Apollo error codes — for example, it reports
+`GRAPHQL_VALIDATION_FAILED` as `validation` and `UNAUTHENTICATED` as `auth` —
+and falls back to `resolver` for anything it doesn't recognize:
 
-   In your project's `docs/` folder (where `zudoku.config.tsx` lives), install
-   the plugin:
+```json title="config/policies.json"
+{
+  "policies": [
+    {
+      "name": "graphql-analytics",
+      "policyType": "graphql-analytics-outbound",
+      "handler": {
+        "export": "GraphqlAnalyticsOutboundPolicy",
+        "module": "$import(@zuplo/runtime)",
+        "options": {
+          "errorCodeClassification": {
+            "RATE_LIMITED": "resolver",
+            "NOT_LOGGED_IN": "auth"
+          },
+          "defaultErrorClass": "resolver",
+          "logErrors": true
+        }
+      }
+    }
+  ]
+}
+```
 
-   ```bash
-   npm install @zudoku/plugin-graphql
-   ```
+- `errorCodeClassification` — Maps custom `extensions.code` values your server
+  emits to an error class. Entries merge over, and win against, the built-in
+  Apollo code map. Defaults to none.
+- `defaultErrorClass` — The class for an error whose code is missing or
+  unrecognized. One of `syntax`, `validation`, `auth`, `timeout`, or `resolver`.
+  Defaults to `resolver`.
+- `logErrors` — When `true`, also writes a structured warning to the request log
+  — the message, code, and path of each error, capped at the first 10 — for
+  every errored response. Defaults to `false`.
+- `maxResponseBytes` — The largest response body, in bytes, the policy inspects.
+  Larger responses pass through unscanned, so any errors they carry go
+  unreported. Defaults to `5242880` (5 MiB).
+
+See the
+[GraphQL Analytics policy reference](../policies/graphql-analytics-outbound.mdx)
+for the full classification table and schema.
 
-   The plugin requires `zudoku` `0.80.1` or newer.
+## Document the API in your Dev Portal
 
-2. **Add a schema**
+The `@zudoku/plugin-graphql` package renders a browsable type reference and a
+playground in your Dev Portal, generated from your schema. Register one instance
+per API.
 
-   Drop a GraphQL schema definition language (SDL) file next to your config:
+:::caution{title="Beta"}
 
-   ```graphql title="schema.graphql"
-   type Query {
-     product(id: ID!): Product
-   }
+The GraphQL plugin is in beta.
 
-   type Product {
-     id: ID!
-     name: String!
-     price: Float!
-   }
-   ```
+:::
 
-   Don't have an SDL file handy? Skip this step and introspect a live endpoint
-   at build time with `type: "url"` in the next step — the schema is fetched for
-   you when the portal builds.
+<Stepper>
 
-3. **Register the plugin**
+1. **Register the plugin**
 
    Import `graphqlPlugin` and add an instance per API. The `path` is where the
-   docs mount, and `input` points at your schema:
+   docs mount, and `input` points at your GraphQL endpoint:
 
    ```tsx title="zudoku.config.tsx"
    import { graphqlPlugin } from "@zudoku/plugin-graphql";
@@ -172,15 +209,12 @@ project's working copy — it only works in projects
    const config = {
      plugins: [
        graphqlPlugin({
-         type: "file",
-         input: "./schema.graphql",
+         type: "url",
+         input: "https://graphql.example.com/api",
          path: "/graphql/ecommerce",
          options: {
            title: "E-Commerce GraphQL API",
            description: "Products, orders, and customers.",
-           playground: {
-             endpoint: "https://my-gateway.example.com/graphql",
-           },
          },
        }),
      ],
@@ -189,18 +223,33 @@ project's working copy — it only works in projects
    export default config;
    ```
 
-   Set `playground.endpoint` to the gateway route from the first half of this
-   guide so readers run real queries through your gateway. With a file-based
-   schema the plugin doesn't know where your API lives — leave the endpoint
-   unset and the reference pages still render, but the playground asks you to
-   configure `options.playground.endpoint` before it can run operations.
+   With `type: "url"`, the portal fetches the schema via introspection at build
+   time, and the playground sends operations to that same URL by default. Point
+   `input` at the gateway route from the first half of this guide so readers run
+   real queries through your gateway — or keep the playground separate from the
+   schema source with `options.playground.endpoint`.
+
+   Have a GraphQL schema definition language (SDL) file instead of a live
+   endpoint? Use `type: "file"` and set `input` to the file's path (for example
+   `./schema.graphql`). A file-based schema doesn't tell the plugin where your
+   API lives, so also set `options.playground.endpoint` — without it the
+   reference pages still render, but the playground asks for an endpoint before
+   it can run operations.
+
+   You can register the plugin more than once to document several schemas, each
+   with its own `path`.
+
+   :::note
+
+   New projects ship with `@zudoku/plugin-graphql` in `dependencies` already.
+   Older projects might need to add it to `docs/package.json`. The plugin
+   requires `zudoku` version `0.80.1` or newer.
+   [Update the Dev Portal](../dev-portal/updating.mdx) to get the latest
+   version.
 
-   With `type: "url"`, set `input` to your GraphQL endpoint's URL instead: the
-   schema is fetched via introspection when the portal builds, and the
-   playground defaults to that same URL. You can register the plugin more than
-   once to document several schemas, each with its own `path`.
+   :::
 
-4. **Link it in the navigation**
+2. **Link it in the navigation**
 
    Point a navigation link at the instance's `path`. Set `stack: true` so the
    API's own pages render as a stacked sub-navigation instead of expanding
@@ -270,6 +319,8 @@ playground runs operations against your configured endpoint.
   introspection policies
 - [Testing GraphQL queries](./testing-graphql.mdx) — test the endpoint from the
   Zuplo Portal or external tools
+- [GraphQL analytics](../analytics/tabs/graphql.md) — monitor operation volume,
+  latency, and error classes once traffic flows
 - [URL Rewrite handler](../handlers/url-rewrite.mdx) — full reference for the
   handler GraphQL routes use
 - [MCP Server GraphQL endpoints](../mcp-server/graphql.mdx) — expose GraphQL

package/docs/articles/mcp-quickstart-local.mdx

@@ -39,7 +39,8 @@ If you're not familiar with Zuplo, it's recommended to go through
 
 1. Create an **MCP Server**
 
-   On your `routes.oas.json` file, choose **Add** and then **MCP Server**.
+   On your `routes.oas.json` file, choose **Add** and then **Dynamic OpenAPI to
+   MCP Server**.
 
    ![Add Route](../../public/media/mcp-quickstart/add-mcp-route.png)
 

package/docs/articles/mcp-quickstart.mdx

@@ -21,8 +21,12 @@ If you're not familiar with Zuplo, it's recommended to go through the
    Let's import an OpenAPI document. You can download this one here
    [todo-openapi.json](https://download-open-api-main-fae215f.d2.zuplo.dev/todo-openapi).
 
+   <ModalScreenshot size="sm">
+
    ![Import OpenAPI](../../public/media/mcp-quickstart/import-openapi.png)
 
+   </ModalScreenshot>
+
    Select the **Code** tab (1), then choose the `routes.oas.json` file (2) and
    choose **Import OpenAPI** (3).
 
@@ -49,7 +53,8 @@ If you're not familiar with Zuplo, it's recommended to go through the
 
 1. Create an **MCP Server**
 
-   On your `routes.oas.json` file, choose **Add** and then **MCP Server** (3)
+   On your `routes.oas.json` file, choose **Add** and then **Dynamic OpenAPI to
+   MCP Server** (3)
 
    ![Add Route](../../public/media/mcp-quickstart/add-mcp-route.png)
 

package/docs/articles/multiple-auth-policies.mdx

@@ -10,8 +10,8 @@ tags:
 
 Sometimes multiple types of authentication are needed on an API. For example, an
 API could support JWT Authentication and API Key authentication or two different
-OAuth providers (for example Azure AD for employees and Auth0 for partners).
-Configuring multiple policies in Zuplo can be done in several ways.
+OAuth providers (for example Microsoft Entra ID for employees and Auth0 for
+partners). Configuring multiple policies in Zuplo can be done in several ways.
 
 ## JWT and API Key Authentication
 

package/docs/articles/openapi.mdx

@@ -15,7 +15,8 @@ this is an OpenAPI document used for routing.
 You can use the Route Designer to build your routes, which will be creating an
 OpenAPI document in the background for you (check it out in the **JSON View**).
 
-You can also **import an OpenAPI** document by clicking the **Open API** tab.
+You can also **import an OpenAPI** document by clicking the **Import** button in
+the Route Designer.
 
 ![Import Open API](../../public/media/open-api/image-1.png)
 
@@ -39,8 +40,12 @@ document and will keep your Zuplo settings intact, while overwriting everything
 else from your imported OpenAPI docs. This creates a great workflow, whatever
 toolset you use.
 
+<ModalScreenshot>
+
 ![Import OpenAPI dialog](../../public/media/open-api/28512107-8c41-4974-8319-c9ec50734331.png)
 
+</ModalScreenshot>
+
 What's more, you can now have more confidence that your OpenAPI represents the
 truth of your API implementation - because it now drives the configuration of
 your gateway.

package/docs/articles/rename-or-move-project.mdx

@@ -23,8 +23,12 @@ disconnect the project from Source Control.
 Next create a new project in the correct account if moving accounts or with the
 correct name. Choose the `Advanced` option on the new project dialog.
 
+<ModalScreenshot>
+
 ![Import existing project](../../public/media/source-control/image-1.png)
 
+</ModalScreenshot>
+
 You should see a list of organizations and repositories - pick the source
 repository you wanted to move and click **Create Project from repository**.
 

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

@@ -29,8 +29,12 @@ Open the **Settings** section of your project and select **Environment
 Variables**. Create a new variable and name it `BACKEND_SECRET`. Set the value
 to a secure, random value. Ensure that the value is marked as a secret.
 
+<ModalScreenshot>
+
 ![Set Environment Variable](../../public/media/securing-backend-shared-secret/image.png)
 
+</ModalScreenshot>
+
 ### Step 2: Create a set header policy
 
 Create a policy that sets the `BACKEND_SECRET` as a header on the request to
@@ -40,8 +44,12 @@ is sent to your backend.
 Navigate to the route you want to secure and add a new policy. Select the **Add
 or Set Request Headers** policy type and configure it as follows:
 
+<ModalScreenshot>
+
 ![Set Header Policy](../../public/media/securing-backend-shared-secret/image-1.png)
 
+</ModalScreenshot>
+
 The configuration uses the environment variable via the `$env(BACKEND_SECRET)`
 selector as shown below.
 
@@ -98,10 +106,10 @@ interested in using this option please contact us at `support@zuplo.com`.
 Utilize the IAM controls provided by your Cloud host to secure inbound requests
 and allow only authorized service principals access to your service.
 
-- For Azure users, you can user our
+- For Azure users, you can use the
   [Upstream Azure AD Service Auth](../policies/upstream-azure-ad-service-auth-inbound.mdx)
-  policy. This uses Azure AD App registrations to create a token that Zuplo will
-  send to requests to Azure.
+  policy. This uses Microsoft Entra ID (formerly Azure AD) App registrations to
+  create a token that Zuplo sends with requests to Azure.
 
 - For GCP users, you can use our
   [Upstream GCP Service AUth](../policies/upstream-gcp-service-auth-inbound.mdx)

package/docs/articles/source-control-setup-github.mdx

@@ -130,8 +130,12 @@ If you have an existing GitHub repository that contains a Zuplo project, you can
 connect to that repository when you create a new project. Select **Import
 existing project** then select your GitHub organization and repository.
 
+<ModalScreenshot>
+
 ![Import existing project to Zuplo](../../public/media/source-control/image-1.png)
 
+</ModalScreenshot>
+
 ## What's Included
 
 With GitHub connected, you get:

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

@@ -226,8 +226,8 @@ period of inactivity is slow. Subsequent requests are fast.
 
 ### Analytics Dashboard
 
-Zuplo's analytics dashboard provides at-a-glance visibility into your API's
-performance. Use it to:
+Zuplo's analytics dashboard, in the **Observability** tab of your project,
+provides at-a-glance visibility into your API's performance. Use it to:
 
 - Identify slow endpoints by reviewing request latency data
 - Filter by route, API key, or time period to isolate patterns

package/docs/articles/troubleshooting.md

@@ -177,9 +177,9 @@ const response = await fetch("https://api.example.com/data", {
 ### Portal live logs
 
 The Zuplo Portal provides real-time log viewing for deployed environments. Open
-the [**Environments**](https://portal.zuplo.com/+/account/project/environments)
-tab in your project, select the deployed environment, and open the logs tab to
-see live request logs and any messages logged with `context.log`.
+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`.
 
 ### Using context.log
 

package/docs/dedicated/akamai/architecture.mdx

@@ -229,7 +229,7 @@ Zuplo and your backend services. For complete documentation, see
 | **Shared Secret / API Key** | Add a secret header to requests that only the gateway knows. Simple to implement and widely used by companies like Stripe and Supabase.            |
 | **Zuplo JWT Service**       | Issue signed JWTs that your backend validates using Zuplo's JWKS endpoint. Provides cryptographic proof that requests originate from your gateway. |
 | **mTLS (Mutual TLS)**       | Certificate-based authentication where both gateway and backend present certificates. Provides zero-trust security for enterprise requirements.    |
-| **Cloud Provider IAM**      | Use AWS IAM, GCP Identity-Aware Proxy, or Azure AD to authorize requests. No credentials to manage - uses federated identity.                      |
+| **Cloud Provider IAM**      | Use AWS IAM, GCP Identity-Aware Proxy, or Microsoft Entra ID to authorize requests. No credentials to manage - uses federated identity.            |
 | **Secure Tunnel (VPN)**     | WireGuard-based tunnel for backends that can't be exposed to the internet. Useful for on-premise or bare-metal deployments.                        |
 | **Private Network**         | VPC peering, PrivateLink, or Transit Gateway for private connectivity without traversing the public internet.                                      |
 
@@ -238,14 +238,14 @@ Zuplo and your backend services. For complete documentation, see
 While most authentication methods work anywhere, some approaches are better
 suited for specific scenarios:
 
-| Backend Location             | Recommended Methods                               | Notes                                                                       |
-| ---------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------- |
-| **Akamai Connected Cloud**   | Shared secret, Zuplo JWT, mTLS                    | All methods work well; choose based on your security requirements           |
-| **AWS**                      | AWS IAM (federated identity), mTLS, shared secret | IAM provides credential-free auth; works with Lambda, API Gateway, ECS, EKS |
-| **GCP**                      | GCP Identity-Aware Proxy, GCP Service Auth, mTLS  | IAP provides zero-trust access to Cloud Run, GKE, and Compute Engine        |
-| **Azure**                    | Azure AD Service Auth, mTLS, shared secret        | Azure AD integrates with App Service, Functions, and AKS                    |
-| **On-Premise / Data Center** | Secure tunnel, mTLS, shared secret                | Tunnel allows private connectivity; mTLS provides strong authentication     |
-| **Third-Party APIs**         | Shared secret, API keys, mTLS                     | Use whatever the third-party API supports                                   |
+| Backend Location             | Recommended Methods                                  | Notes                                                                       |
+| ---------------------------- | ---------------------------------------------------- | --------------------------------------------------------------------------- |
+| **Akamai Connected Cloud**   | Shared secret, Zuplo JWT, mTLS                       | All methods work well; choose based on your security requirements           |
+| **AWS**                      | AWS IAM (federated identity), mTLS, shared secret    | IAM provides credential-free auth; works with Lambda, API Gateway, ECS, EKS |
+| **GCP**                      | GCP Identity-Aware Proxy, GCP Service Auth, mTLS     | IAP provides zero-trust access to Cloud Run, GKE, and Compute Engine        |
+| **Azure**                    | Microsoft Entra ID Service Auth, mTLS, shared secret | Microsoft Entra ID integrates with App Service, Functions, and AKS          |
+| **On-Premise / Data Center** | Secure tunnel, mTLS, shared secret                   | Tunnel allows private connectivity; mTLS provides strong authentication     |
+| **Third-Party APIs**         | Shared secret, API keys, mTLS                        | Use whatever the third-party API supports                                   |
 
 ### Choosing an authentication method
 

package/docs/dev-portal/zudoku/components/browser-window.mdx

@@ -0,0 +1,94 @@
+---
+title: Browser Window
+sidebar_icon: app-window
+---
+
+import { BrowserWindow } from "zudoku/components";
+import { Button } from "zudoku/ui/Button";
+
+A mock browser window for presenting UI previews, screenshots-as-code, or full page layouts in your
+documentation. It renders its children inside a browser-style frame with a URL bar and an optional
+zoom control — the current scale is displayed like in a real browser and readers can zoom in and out
+themselves.
+
+## Import
+
+```tsx
+import { BrowserWindow } from "zudoku/components";
+```
+
+## Usage
+
+<BrowserWindow>
+  <div className="flex flex-col items-center gap-3 p-10 text-center">
+    <span className="text-2xl font-bold">Hello, world!</span>
+    <p className="text-muted-foreground">Any content renders inside the browser frame.</p>
+    <Button>Get started</Button>
+  </div>
+</BrowserWindow>
+
+```tsx
+<BrowserWindow>
+  <div className="flex flex-col items-center gap-3 p-10 text-center">
+    <span className="text-2xl font-bold">Hello, world!</span>
+    <p className="text-muted-foreground">Any content renders inside the browser frame.</p>
+    <Button>Get started</Button>
+  </div>
+</BrowserWindow>
+```
+
+## Scale
+
+Use the `scale` prop to set the initial zoom of the content. This is useful for presenting
+full-width layouts, like a landing page, at a reduced size. Passing a `scale` enables the zoom
+control in the toolbar showing the current scale — readers can change it with the `+`/`-` buttons or
+click the percentage to reset it, just like in a real browser. Without a `scale`, the zoom control
+is hidden and the content renders at full size (pass `scale={1}` to start at 100% with the control
+enabled).
+
+<BrowserWindow scale={0.5}>
+  <div className="flex flex-col items-center gap-3 p-10 text-center">
+    <span className="text-4xl font-bold">Scaled to 50%</span>
+    <p className="text-muted-foreground">
+      The content is laid out at full width and scaled down to fit.
+    </p>
+  </div>
+</BrowserWindow>
+
+```tsx
+<BrowserWindow scale={0.5}>
+  <div className="flex flex-col items-center gap-3 p-10 text-center">
+    <span className="text-4xl font-bold">Scaled to 50%</span>
+    <p className="text-muted-foreground">
+      The content is laid out at full width and scaled down to fit.
+    </p>
+  </div>
+</BrowserWindow>
+```
+
+Scaling affects layout, not just size: at `scale={0.5}` the content is laid out at twice the
+container width and scaled down, so responsive layouts behave as if viewed on a larger screen.
+
+## URL
+
+Set the `url` prop to change the address shown in the URL bar (defaults to `localhost:3000`):
+
+<BrowserWindow url="https://developers.example.com">
+  <p className="p-10 text-center text-muted-foreground">Your developer portal</p>
+</BrowserWindow>
+
+```tsx
+<BrowserWindow url="https://developers.example.com">
+  <p className="p-10 text-center text-muted-foreground">Your developer portal</p>
+</BrowserWindow>
+```
+
+## Props
+
+| Prop               | Type        | Description                                                                                                                                      |
+| ------------------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `url`              | `string`    | Address displayed in the URL bar. Defaults to `localhost:3000`.                                                                                  |
+| `scale`            | `number`    | Initial zoom of the content (e.g. `0.75` for 75%). Enables the zoom control; if omitted, the control is hidden and content renders at full size. |
+| `className`        | `string`    | Additional classes for the outer frame.                                                                                                          |
+| `contentClassName` | `string`    | Additional classes for the content viewport.                                                                                                     |
+| `children`         | `ReactNode` | The content rendered inside the browser window.                                                                                                  |