zuplo 6.70.71 → 6.71.0

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

@@ -62,7 +62,7 @@ Remove the `demo` parameter from the URL to return to your real data.
 ## Scope: account vs project
 
 - **Account scope** aggregates across every project in the account. The Requests
-  tab adds **Project Name** and **Deployment Name** as breakdowns; click a
+  section adds **Project Name** and **Deployment Name** as breakdowns; click a
   project name to drill into project scope.
 - **Project scope** filters to a single project and adds an **Environment**
   selector (Working Copy, Production, Preview, Other) in the top bar.

package/docs/analytics/overview.md

@@ -19,12 +19,15 @@ you're answering "is anyone actually using this endpoint?"
 
 ## How to access
 
-Open **Analytics** in the Zuplo portal sidebar. The page works at two scopes:
+Analytics lives in the **Observability** tab of the Zuplo Portal, alongside
+**Logs** and **Traces**. The page works at two scopes:
 
 - **Account scope**: aggregates across every project in your account. Open
-  [Account Analytics](https://portal.zuplo.com/+/account/analytics).
-- **Project scope**: open a project, then click **Analytics**. Filters to one
-  project and adds an **Environment** selector.
+  [**Observability → Analytics**](https://portal.zuplo.com/+/account/observability/analytics)
+  at the account level.
+- **Project scope**: open a project, click **Observability**, then select
+  **Analytics**. This view filters to one project and adds an **Environment**
+  selector.
 
 ## What's in this section
 
@@ -32,7 +35,7 @@ Open **Analytics** in the Zuplo portal sidebar. The page works at two scopes:
   demo mode, retention.
 - [Shared controls](./shared-controls.md): time range, filters, environment
   selector, banners, URL state.
-- Tabs:
+- Sections:
   - [Requests](./tabs/requests.md): overall traffic, latency, errors.
   - [Origins](./tabs/origins.md): backend performance.
   - [Consumers](./tabs/consumers.md): per-consumer breakdowns.
@@ -46,11 +49,12 @@ Open **Analytics** in the Zuplo portal sidebar. The page works at two scopes:
     percentile defined once.
   - [URL parameters](./reference/url-parameters.md): permalink reference.
 
-## Tab visibility
+## Section visibility
 
-You'll see a subset of tabs depending on your plan and project setup:
+Analytics is split into sections, listed in a sidebar on the left of the page.
+You'll see a subset of sections depending on your plan and project setup:
 
-| Tab       | When it appears                                            |
+| Section   | When it appears                                            |
 | --------- | ---------------------------------------------------------- |
 | Requests  | All accounts with advanced analytics enabled.              |
 | Origins   | The project uses managed-edge origins.                     |

package/docs/analytics/reference/metrics-glossary.md

@@ -4,7 +4,7 @@ sidebar_label: "Metrics Glossary"
 ---
 
 This page defines every term used in the Analytics dashboards once. KPI tables
-on tab pages link here for depth.
+on section pages link here for depth.
 
 ## HTTP status classes
 
@@ -43,7 +43,7 @@ longer. P95 is the standard tail-latency metric.
 outlier behavior that P95 may smooth over.
 
 **Latency distribution histogram.** Bands at P10, P50, P90, P95, P99. Clicking a
-band on the Requests tab filters to requests in that duration range.
+band in the Requests section filters to requests in that duration range.
 
 ## Active edge instances
 
@@ -81,7 +81,7 @@ MCP events use these outcome classes:
 
 ## GraphQL error classes
 
-The GraphQL tab groups errors by where they arise:
+The GraphQL section groups errors by where they arise:
 
 | Class      | Meaning                                                          |
 | ---------- | ---------------------------------------------------------------- |

package/docs/analytics/shared-controls.md

@@ -3,19 +3,20 @@ title: "Shared Controls"
 sidebar_label: "Shared Controls"
 ---
 
-Every Analytics tab uses the same set of controls at the top of the page: a time
-range picker, a filter bar, and (at project scope) an environment selector.
+Every Analytics section uses the same set of controls at the top of the page: a
+time range picker, a filter bar, and (at project scope) an environment selector.
 State persists to the URL so you can share or bookmark any view.
 
 ## When to use this
 
-- Narrow a tab to a time window, environment, or set of filter values.
+- Narrow a section to a time window, environment, or set of filter values.
 - Build a shareable link to a specific view.
 - Understand what each banner across the top of the page means.
 
 ## Time range
 
-The time range picker controls every chart, table, and KPI on the active tab.
+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.
 
@@ -28,7 +29,7 @@ for [preset]** tooltip. See
 
 ## Filters
 
-Filters render as removable pills in a sticky bar at the top of the tab. Add a
+Filters render as removable pills in a sticky bar at the top of the page. Add a
 filter from any breakdown table by clicking a value, or build one manually.
 
 **Match modes.** Each filter uses one of:
@@ -46,9 +47,9 @@ filter from any breakdown table by clicking a value, or build one manually.
 **Clearing.** Remove a single pill with its **×**, or click **Clear all
 filters** to reset.
 
-**Disabled fields.** Some fields are grayed out on tabs where they don't apply.
-For example, `originHost` is unavailable on Requests, Consumers, and Agents;
-`userSub` is unavailable on Origins.
+**Disabled fields.** Some fields are grayed out in sections where they don't
+apply. For example, `originHost` is unavailable on Requests, Consumers, and
+Agents; `userSub` is unavailable on Origins.
 
 ## Environment selector
 
@@ -103,9 +104,9 @@ Banners appear at the top of the page in this priority order:
 
 ## Loading and empty states
 
-Each tab uses a shape-aware skeleton while the first request is in flight. The
-product analytics tabs (MCP, GraphQL) suppress that skeleton briefly to avoid
-flashing when data is already cached. Empty states on those tabs include a short
+Each section uses a shape-aware skeleton while the first request is in flight.
+The product analytics sections (MCP, GraphQL) suppress that skeleton briefly to
+avoid flashing when data is already cached. Empty states there include a short
 description and a "Read the … docs" link to the relevant product section.
 
 ## Status colors

package/docs/analytics/tabs/agents.md

@@ -3,9 +3,9 @@ title: "Agents"
 sidebar_label: "Agents"
 ---
 
-The **Agents** tab isolates AI agent traffic: requests classified as coming from
-ChatGPT, Claude.ai, Cursor, GPTBot, and similar clients. It's a focused view;
-browsers, webhooks, and generic SDK callers are excluded.
+The **Agents** section isolates AI agent traffic: requests classified as coming
+from ChatGPT, Claude.ai, Cursor, GPTBot, and similar clients. It's a focused
+view; browsers, webhooks, and generic SDK callers are excluded.
 
 ## When to use this
 
@@ -27,7 +27,7 @@ browsers, webhooks, and generic SDK callers are excluded.
 ## Charts
 
 **Request Volume.** Stacked bars by status class. Granularity is always hourly
-on this tab.
+in this section.
 
 **Agent Error Rates.** 4xx and 5xx over time. _What to look for:_ divergence
 between agents is the headline signal. If Cursor shows a 12% 4xx rate while
@@ -48,7 +48,7 @@ your endpoint.
 | 4xx sparkline   | Inline trend over the window.    |
 | 5xx sparkline   | Inline trend over the window.    |
 
-Searchable and sortable on any column. Click a row to filter the tab to that
+Searchable and sortable on any column. Click a row to filter the section to that
 agent. **Show more** loads the next 50.
 
 ## Classified agents
@@ -57,12 +57,12 @@ The classifier currently recognizes: ChatGPT, Claude.ai, Cursor, Claude Code,
 GPTBot, Perplexity, Cline, Continue, OpenAI SDK, Anthropic SDK, Google AI,
 Common Crawl. The list expands over time.
 
-Unclassified traffic is excluded from the Agents tab.
+The Agents section excludes unclassified traffic.
 
 :::warning
 
-Agent charts use a dedicated hourly rollup. Filtering other tabs by agent isn't
-supported. Use the Agents tab to drill into an individual agent.
+Agent charts use a dedicated hourly rollup. Filtering other sections by agent
+isn't supported. Use the Agents section to drill into an individual agent.
 
 :::
 
@@ -73,10 +73,10 @@ The filter bar applies. `originHost` is not applicable here. See
 
 ## Troubleshooting
 
-**The Agents tab 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 tab
-looks like. See [Access and entitlements](../access-and-entitlements.md).
+**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).
 
 **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
@@ -84,5 +84,5 @@ traffic that doesn't identify itself is excluded. If you believe an agent should
 be classified, send the User-Agent string to your Zuplo contact.
 
 **An agent shows zero requests but appears in the table.** Filters on the rest
-of the tab may be excluding its traffic for the current window. Clear filters to
-verify.
+of the section may be excluding its traffic for the current window. Clear
+filters to verify.

package/docs/analytics/tabs/consumers.md

@@ -3,10 +3,10 @@ title: "Consumers"
 sidebar_label: "Consumers"
 ---
 
-The **Consumers** tab breaks traffic down by API consumer: anyone calling your
-gateway, whether authenticated or anonymous. Use it to see who your noisiest
-callers are, who's hitting errors, and which consumers experience the slowest
-latency.
+The **Consumers** section breaks traffic down by API consumer: anyone calling
+your gateway, whether authenticated or anonymous. Use it to see who your
+noisiest callers are, who's hitting errors, and which consumers experience the
+slowest latency.
 
 ## When to use this
 
@@ -48,12 +48,12 @@ looking at one consumer or all of them.
 | 5xx sparkline   | Inline trend over the window.                                       |
 
 The table is searchable and sortable on any column (default: requests
-descending). Clicking a row filters the entire tab to that consumer. **Show
+descending). Clicking a row filters the entire section to that consumer. **Show
 more** loads the next 50.
 
 ## Filters
 
-The filter bar applies. `originHost` is not applicable on this tab. See
+The filter bar applies. `originHost` doesn't apply in this section. See
 [Shared controls](../shared-controls.md#filters).
 
 ## Troubleshooting

package/docs/analytics/tabs/graphql.md

@@ -3,7 +3,7 @@ title: "GraphQL"
 sidebar_label: "GraphQL"
 ---
 
-The **GraphQL** tab breaks traffic down by GraphQL operation: the queries,
+The **GraphQL** section breaks traffic down by GraphQL operation: the queries,
 mutations, and subscriptions clients send through routes you've marked as
 GraphQL endpoints. Use it to find your most-used operations, separate validation
 and resolver errors, and see how much of each operation's latency falls in your
@@ -64,13 +64,14 @@ The filter bar applies. See [Shared controls](../shared-controls.md#filters).
 
 ## Troubleshooting
 
-**The GraphQL tab is empty.** No GraphQL operations arrived in the selected
+**The GraphQL section is empty.** No GraphQL operations arrived in the selected
 window. Operations appear once a client sends a query, mutation, or subscription
 through a route you've marked as a GraphQL endpoint. See
 [GraphQL on Zuplo](../../articles/graphql.mdx) for how to mark a route.
 
-**The tab isn't visible.** Visibility requires at least one route you've marked
-as a GraphQL endpoint. See [GraphQL on Zuplo](../../articles/graphql.mdx).
+**The section isn't visible.** Visibility requires at least one route you've
+marked as a GraphQL endpoint. See
+[GraphQL on Zuplo](../../articles/graphql.mdx).
 
 **Total latency is high but resolver latency is low.** The operation spends its
 time outside your resolvers. Check the gateway policies on the GraphQL route —

package/docs/analytics/tabs/mcp.md

@@ -3,8 +3,8 @@ title: "MCP"
 sidebar_label: "MCP"
 ---
 
-The **MCP** tab shows Model Context Protocol traffic through Zuplo: OAuth and
-auth decisions, virtual-server routing, capability and tool invocations,
+The **MCP** section shows Model Context Protocol traffic through Zuplo: OAuth
+and auth decisions, virtual-server routing, capability and tool invocations,
 JSON-RPC method usage, and upstream MCP server health. It covers both traffic
 that flows _to_ an MCP fleet through Zuplo's gateway and activity _inside_ MCP
 servers you host on Zuplo. It's visible when the project type is **standard**
@@ -68,12 +68,12 @@ The filter bar applies. See [Shared controls](../shared-controls.md#filters).
 
 ## Troubleshooting
 
-**The MCP tab is empty.** No MCP events arrived in the selected window. Once a
-client connects and invokes a capability or tool, the dashboard populates.
+**The MCP section is empty.** No MCP events arrived in the selected window. Once
+a client connects and invokes a capability or tool, the dashboard populates.
 
-**The tab isn't visible.** Visibility requires project type **standard** with
-MCP in use — either an MCP gateway that routes to upstream servers, or an MCP
-server you host on Zuplo.
+**The section isn't visible.** Visibility requires project type **standard**
+with MCP in use — either an MCP gateway that routes to upstream servers, or an
+MCP server you host on Zuplo.
 
 **Errors show but Failure Origins is empty.** Zuplo classifies failure origins
 server-side from event metadata. Events without a clear origin classification

package/docs/analytics/tabs/origins.md

@@ -3,9 +3,9 @@ title: "Origins"
 sidebar_label: "Origins"
 ---
 
-The **Origins** tab shows backend performance: how each upstream host you proxy
-to is performing in terms of volume, error rate, and latency. It's visible when
-the project uses managed-edge origins.
+The **Origins** section shows backend performance: how each upstream host you
+proxy to is performing in terms of volume, error rate, and latency. It's visible
+when the project uses managed-edge origins.
 
 ## When to use this
 
@@ -65,18 +65,19 @@ The table is hidden when no tunnel traffic is present.
 
 ## Filters
 
-The filter bar applies, with one exception: `userSub` is not applicable on this
-tab. See [Shared controls](../shared-controls.md#filters).
+The filter bar applies, with one exception: `userSub` doesn't apply in this
+section. See [Shared controls](../shared-controls.md#filters).
 
 ## Troubleshooting
 
-**The Origins tab isn't visible.** It appears only when the project uses
-managed-edge origins. If your project routes traffic differently, the tab is
+**The Origins section isn't visible.** It appears only when the project uses
+managed-edge origins. If your project routes traffic differently, the section is
 hidden.
 
 **Service Tunnels table is missing.** That table only renders when at least one
 origin is reached over a service tunnel.
 
-**A 5xx spike on one origin doesn't match the Requests tab.** If you've filtered
-the Requests tab to a different route or status class, totals won't match. Clear
-filters or compare with the same filters applied on both tabs.
+**A 5xx spike on one origin doesn't match the Requests section.** If you've
+filtered the Requests section to a different route or status class, totals won't
+match. Clear filters or apply the same filters in both sections before
+comparing.

package/docs/analytics/tabs/requests.md

@@ -3,9 +3,9 @@ title: "Requests"
 sidebar_label: "Requests"
 ---
 
-The **Requests** tab is the default Analytics overview: every request through
-your gateway in the selected time window, with charts and breakdowns for volume,
-latency, and errors.
+The **Requests** section is the default Analytics overview: every request
+through your gateway in the selected time window, with charts and breakdowns for
+volume, latency, and errors.
 
 ## When to use this
 
@@ -44,7 +44,8 @@ subset of requests.
 **Error Rate.** 4xx and 5xx rates plotted over time.
 
 **Latency Distribution.** A histogram of P10, P50, P90, P95, and P99 buckets.
-Click a band to filter the rest of the tab to requests in that duration range.
+Click a band to filter the rest of the section to requests in that duration
+range.
 
 **Active Instances.** Distinct active edge instances over time. A rough
 indicator of how widely your traffic is distributed across gateway workers.
@@ -76,7 +77,7 @@ Clicking any value applies an `equals` filter for that field.
 
 ## Filters
 
-The full filter bar applies. `originHost` is not applicable on this tab. See
+The full filter bar applies. `originHost` doesn't apply in this section. See
 [Shared controls](../shared-controls.md#filters) for match modes and the filter
 pill UI.
 

package/docs/articles/accounts/enterprise-sso.mdx

@@ -8,8 +8,9 @@ using a third-party identity provider.
 
 <EnterpriseFeature name="Single Sign On" />
 
-Zuplo uses Auth0 to manage enterprise SSO, so we can support essentially any
-Identity Provider. Common options are Azure AD, Okta, Google Workspace, etc.
+Zuplo uses Auth0 to manage enterprise SSO, so it can support essentially any
+identity provider. Common options are Microsoft Entra ID, Okta, Google
+Workspace, etc.
 
 ## Configuring your Identity Provider
 
@@ -85,14 +86,15 @@ role-based access control isn't enabled, new users will be added as an Admin.
 
 ### What SSO Providers does Zuplo Support?
 
-Zuplo uses Auth0 to manage enterprise SSO, so we can support essentially any SSO
-provider required. Common options are Azure AD, Okta, Google Workspace, etc.
+Zuplo uses Auth0 to manage enterprise SSO, so it can support essentially any SSO
+provider required. Common options are Microsoft Entra ID, Okta, Google
+Workspace, etc.
 
 ### What happens when SSO is enabled for my organization?
 
 When SSO is enabled, you'll use your organization's identity provider (like Okta
-or Azure AD) to log into Zuplo. This provides enhanced security and streamlines
-access management for your team.
+or Microsoft Entra ID) to log into Zuplo. This provides enhanced security and
+streamlines access management for your team.
 
 If you previously had a Zuplo account with the same email address, your SSO
 login will be treated as the primary method going forward.

package/docs/articles/api-key-administration.mdx

@@ -27,8 +27,12 @@ When you first open the API Key Bucket, you won't have any API Keys created.
 To add a new API Key Consumer click the **Create Consumer** button and complete
 the form.
 
+<ModalScreenshot>
+
 ![New API Key Consumer](../../public/media/api-key-administration/image-4.png)
 
+</ModalScreenshot>
+
 Once a consumer is created, you can view or copy the API Key by clicking the
 icons shown.
 

package/docs/articles/bypass-policy-for-testing.mdx

@@ -98,8 +98,12 @@ the API Key Bucket you want to use and click **Create Consumer**. Enter a name
 for the consumer. Set the metadata to include the `testApiKey` flag as shown
 below.
 
+<ModalScreenshot>
+
 ![Test API Key](../../public/media/bypass-policy-for-testing/image.png)
 
+</ModalScreenshot>
+
 Now when you call the API with the test API Key, the `monetization-inbound`
 policy will be bypassed.
 

package/docs/articles/environment-variables.mdx

@@ -29,10 +29,14 @@ code, see the
 To set environment variables in your project, click **Settings** and then select
 **Environment Variables**.
 
-To create a new variable, click **Add new variable**.
+To create a new variable, click **Add variable**.
+
+<ModalScreenshot>
 
 ![Adding a new environment variable](../../public/media/environment-variables/bec84962-0139-4371-b3fd-a30e70860169.png)
 
+</ModalScreenshot>
+
 Enter the name and value of your environment variable and select if you would
 like the value to be a secret or a regular value.
 

package/docs/articles/environments.mdx

@@ -120,8 +120,8 @@ portal.zuplo.com but you can switch into those environments to perform a number
 of functions, such as:
 
 - edit API consumers for this environment
-- view analytics for this environment
-- view Live Logs for this environment
+- view logs, traces, and analytics for this environment in the **Observability**
+  tab
 
 ## Different Backends per Environment
 

package/docs/articles/graphql.mdx

@@ -132,8 +132,10 @@ project's working copy — it only works in projects
 
 1. **Install the plugin**
 
-   In your project's `docs/` folder (where `zudoku.config.tsx` lives), install
-   the plugin:
+   Check `docs/package.json` first — new projects ship with
+   `@zudoku/plugin-graphql` already listed in `dependencies`, so there's nothing
+   to install. Only older projects need to add it. In your project's `docs/`
+   folder (where `zudoku.config.tsx` lives), install the plugin:
 
    ```bash
    npm install @zudoku/plugin-graphql
@@ -141,30 +143,10 @@ project's working copy — it only works in projects
 
    The plugin requires `zudoku` `0.80.1` or newer.
 
-2. **Add a schema**
-
-   Drop a GraphQL schema definition language (SDL) file next to your config:
-
-   ```graphql title="schema.graphql"
-   type Query {
-     product(id: ID!): Product
-   }
-
-   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.
-
-3. **Register the plugin**
+2. **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 +154,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 +168,23 @@ 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 schema is fetched via introspection when the portal
+   builds, 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.
 
-   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`.
+   You can register the plugin more than once to document several schemas, each
+   with its own `path`.
 
-4. **Link it in the navigation**
+3. **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

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**.