zuplo 6.70.27 → 6.70.29

package/docs/articles/accounts/switching-between-accounts.mdx

@@ -0,0 +1,160 @@
+---
+title: Switching Between Accounts
+sidebar_label: Switching Accounts
+---
+
+If you belong to more than one Zuplo account (for example, your own personal
+account plus an account you were invited to join), you can switch between them
+in the Zuplo Portal without signing out.
+
+This guide covers accepting an invitation, finding the account switcher, and
+troubleshooting common issues when you can't see an account you expect to have
+access to.
+
+:::caution{title="Sign in with the same identity"}
+
+The invitation must be accepted using the same identity (email address and
+sign-in method) it was sent to. Zuplo treats Google sign-in, GitHub sign-in, and
+email-password as separate identities, even when they share an email address. If
+you click an invitation while signed in with a different identity, the
+invitation does not apply.
+
+:::
+
+## Accept an account invitation
+
+When an account admin invites you, Zuplo sends an invitation email to the
+address they entered.
+
+<Stepper>
+
+1. Open the invitation email and click the link to accept the invitation.
+1. If you are not already signed in to the Zuplo Portal, sign in with the **same
+   email address and method** the invitation was sent to. See
+   [I accepted the invitation but I don't see the account](#i-accepted-the-invitation-but-i-dont-see-the-account)
+   if you hit a mismatch.
+1. After signing in, the invited account appears in the **Switch Account**
+   submenu of your avatar dropdown.
+
+</Stepper>
+
+## Switch accounts in the portal
+
+Once you belong to multiple accounts, switch between them from the avatar menu.
+
+<Stepper>
+
+1. Click your avatar in the **top-right corner** of the portal. The currently
+   active account name appears at the top of the dropdown.
+1. Hover over **Switch Account** to open the submenu, which lists every account
+   you belong to.
+1. Select the account you want to switch to.
+1. The portal reloads in the context of the selected account, showing that
+   account's projects, settings, and resources.
+
+</Stepper>
+
+After switching, all navigation within the portal (project lists, account
+settings, billing, logs) reflects the selected account.
+
+## How multi-account membership works
+
+When you first sign up for Zuplo, an account is automatically created for you.
+An admin on another account can then invite you by opening their avatar menu,
+selecting **Account Settings → Members**, clicking **Invite to account**, and
+entering your email address and role. Once you accept, you become a member of
+that account in addition to your own.
+
+Each account is independent. Projects, billing, custom domains, and API keys all
+belong to a specific account. When you switch accounts in the portal, you see
+only the resources that belong to the account you switched into.
+
+## Roles in an invited account
+
+Your role in the invited account determines what you can access. The account
+admin assigns your role at invitation and can update it later. For the full
+permission matrix, see [Role Permissions](./roles-and-permissions.mdx).
+
+:::note
+
+Role-Based Access Control (RBAC) with Developer and Member roles is an
+enterprise feature. On non-enterprise accounts, all invited users are added as
+**Admin** by default.
+
+:::
+
+## Troubleshooting
+
+### I accepted the invitation but I don't see the account
+
+This is almost always an **identity mismatch**. Zuplo supports signing in with
+Google, GitHub, and email-password. Different sign-in methods are treated as
+separate identities, even when the underlying email address is the same.
+
+Work through this checklist:
+
+- **Check the email address on the invitation.** Confirm it matches exactly the
+  email you use to sign in to Zuplo.
+- **Check your sign-in method.** If the invitation was sent to `you@company.com`
+  and you usually sign in with Google OAuth using that same email, that
+  combination should work. But if you also created a separate email-password
+  account with the same address, Zuplo treats those as different identities.
+  Sign in with the method that matches how the invitation was sent.
+- **Click the invitation link again.** Open the original invitation email and
+  click the accept link while signed in with the correct identity. If you were
+  signed in with a different identity the first time, the invitation may have
+  been applied to the wrong account.
+- **Ask the account admin to verify.** The admin can check **Account Settings →
+  Members** to confirm the invitation status. If it shows as pending, it hasn't
+  been accepted yet. The admin can also remove and re-send the invitation to
+  ensure it goes to the right email.
+
+### I see the account but not its projects
+
+If you switched into an account but the project list appears empty or you can't
+open a specific project, check the following:
+
+- **Your account-level role may not include project visibility.** Users with the
+  **Member** role at the account level cannot view projects unless an admin has
+  granted them a project-level role. Ask the account admin to assign you a role
+  on the specific project you need access to. See
+  [Managing Project Members](./managing-project-members.mdx) for details.
+- **The project may require source control access.** Some projects are connected
+  to a GitHub, GitLab, Bitbucket, or Azure DevOps repository. You may need
+  access to the linked repository in addition to your Zuplo project role.
+
+### Why doesn't my invitation link work?
+
+Invitation links can fail for a few reasons:
+
+- **The link is expired or already used.** Ask the account admin to resend the
+  invitation from **Account Settings → Members**.
+- **The link was opened while signed in as the wrong identity.** Sign out, open
+  the invitation in a fresh browser session, and sign in with the address the
+  invitation was sent to.
+
+### Why don't I see the account switcher in my avatar menu?
+
+The **Switch Account** submenu only lists other accounts when you belong to more
+than one. If hovering **Switch Account** shows only your current account, you
+belong to a single account. Ask the relevant account admin to send (or resend)
+an invitation to your address.
+
+### Do I get the invited account's plan features?
+
+Yes. Plan-tier features (Free, Builder, Enterprise) are attached to the
+**account**, not to individual users. While working inside a higher-tier
+account, you have access to all features your role permits on that plan,
+regardless of your personal account's plan.
+
+When you switch back to your personal account, you have access only to the
+features available on your personal account's plan.
+
+## Related topics
+
+- [Managing Account Members](./managing-account-members.mdx): How to invite
+  users and manage their roles (admin perspective).
+- [Managing Project Members](./managing-project-members.mdx): How to grant
+  project-level access to account members.
+- [Role Permissions](./roles-and-permissions.mdx): Full permission matrix for
+  account and project roles.

package/docs/articles/configuring-auth0-for-mcp-auth.mdx

@@ -17,6 +17,15 @@ authentication for your MCP Server.
 
 This guide will assume that you already have a working Auth0 account and tenant.
 
+:::note
+
+This guide is an example of how you can set up your Auth0 tenant for MCP OAuth
+support. It is recommended that you consult the
+[Auth0 documentation](https://auth0.com/ai/docs/mcp/guides/registering-your-mcp-client-application)
+for more information.
+
+:::
+
 ### Create an Auth0 API
 
 First, you will need to create an Auth0 API. This API will be used to represent
@@ -30,18 +39,6 @@ your MCP Server.
    `https://my-gateway.zuplo.dev/mcp`. **The trailing slash isn't required.**
 3. Leave the **Signing Algorithm** as `RS256` and click **Create**.
 
-### Enable Dynamic Client Registration
-
-Next, you will need to enable Dynamic Client Registration for the API you just
-created.
-
-1. In the Auth0 dashboard, navigate to the tenant settings in **Settings** on
-   the left hand sidebar.
-2. Navigate to the **Advanced** tab.
-3. Scroll down to the **Settings** section and check the toggle for **OIDC
-   Dynamic Application Registration**. Also ensure that the **Enable Application
-   Connections** toggle is checked.
-
 ### Configure the Connection
 
 Next, you will need to configure an Auth0 Connection for your API.
@@ -80,12 +77,45 @@ Next, you will need to configure an Auth0 Connection for your API.
    --data '{ "is_domain_connection": true }'
    ```
 
-5. Configure a Default Audience by clicking on Settings > General. Then in the
-   API Authorization Settings, modify the Default Audience. See the Auth0 doc on
-   [API Authorization Settings](https://auth0.com/docs/get-started/tenant-settings#api-authorization-settings)
-   for more information on how to configure a default audience. The audience
-   should be the identifier of the API you created in
-   [Create an Auth0 API](#create-an-auth0-api).
+5. Enable Resource Parameter Compatibility Profile. See the
+   [Auth0 tenant settings docs](https://auth0.com/docs/get-started/tenant-settings)
+   for more information.
+
+After completing these changes to your Auth0 tenant, you will need to enable
+CIMD or DCR (or both) on your Auth0 tenant.
+
+### Enable CIMD for MCP OAuth
+
+To use CIMD for MCP OAuth authentication, do the following:
+
+1. In the Auth0 dashboard, navigate to the tenant settings in **Settings** on
+   the left hand sidebar.
+2. Navigate to the **Advanced** tab.
+3. Scroll down to the **Settings** section and check the toggle for **Client ID
+   Metadata Document (CIMD) Registration**.
+4. Register the MCP clients via their public CIMD client data metadata URL by
+   clicking "Create Application" and then "Import from URL". Note that for all
+   the MCP clients you want to support, you will need to obtain the metadata URL
+   and register each application individually.
+
+See the official
+[Auth0 docs](https://auth0.com/ai/docs/mcp/guides/registering-your-mcp-client-application/manual-cimd-registration)
+for more information.
+
+### Enabling DCR for MCP OAuth
+
+To use DCR for MCP OAuth authentication, do the following:
+
+1. In the Auth0 dashboard, navigate to the tenant settings in **Settings** on
+   the left hand sidebar.
+2. Navigate to the **Advanced** tab.
+3. Scroll down to the **Settings** section and check the toggle for **Dynamic
+   Client Registration (DCR)**. Also ensure that the **Enable Application
+   Connections** toggle is checked.
+
+See the official
+[Auth0 docs](https://auth0.com/ai/docs/mcp/guides/registering-your-mcp-client-application/dynamic-client-registration)
+for more information.
 
 ### Configure OAuth on Zuplo
 
@@ -184,3 +214,13 @@ open the OAuth settings. This will allow you to debug the flow step by step.
 You should be able to hit the **Continue** button in the Inspector UI at each
 step of the flow successfully. If you need more help debugging, see
 [Testing OAuth on Zuplo](../handlers/mcp-server.mdx#oauth-testing).
+
+:::note
+
+When testing CIMD authentication, you will need an MCP client with a CIMD
+compatible client metadata URL. Currently, MCP Inspector does not have this, so
+it is recommended that you test with another client like the Claude Code CLI
+(Client Metadata URI as of May 2026 is
+https://claude.ai/oauth/claude-code-client-metadata).
+
+:::

package/docs/articles/monetization/api-access.mdx

@@ -61,136 +61,6 @@ curl \
   --header "Authorization: Bearer $ZAPI_KEY"
 ```
 
-## Bucket monetization configuration
-
-Each bucket has an optional `MonetizationConfiguration` record that holds
-bucket-wide defaults. The configuration is read by the runtime and the Developer
-Portal.
-
-| Method   | Path                                                 |
-| -------- | ---------------------------------------------------- |
-| `GET`    | `/v3/metering/{bucketId}/monetization-configuration` |
-| `PUT`    | `/v3/metering/{bucketId}/monetization-configuration` |
-| `DELETE` | `/v3/metering/{bucketId}/monetization-configuration` |
-
-The `PUT` endpoint upserts the record. At least one of the four fields below
-must be present. Pass any combination — fields that are omitted retain their
-previous value.
-
-| Field                          | Type               | Description                                                                                                                                                                                                                                                                                                                                                    |
-| ------------------------------ | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `multipleSubscriptionsEnabled` | `boolean`          | Stored on the bucket. Reserved for future enforcement of multi-subscription rules; today the Developer Portal create-subscription path enforces a single active subscription per customer regardless of this flag.                                                                                                                                             |
-| `planOrder`                    | `string[]`         | Plan keys in display order. Drives the pricing page sort and is used by [plan changes](./subscription-lifecycle.md#plan-changes-upgrades-and-downgrades) to decide upgrade vs downgrade — moving to a plan with a higher (or equal) index is treated as an upgrade with `"immediate"` timing; a lower index is a downgrade with `"next_billing_cycle"` timing. |
-| `planSettings`                 | `object`           | Per-plan overrides keyed by plan key. The supported sub-key today is `visiblePhases` — an array of phase keys that should appear on the pricing page. Omitted means no filtering; `[]` hides all phases for that plan.                                                                                                                                         |
-| `maxPaymentOverdueDays`        | `integer` (`>= 0`) | Bucket-level grace period for overdue payments. Used as the lowest-priority value in the resolution chain: customer metadata → plan metadata → this bucket value → built-in default of `3` days. See [Subscription and payment validation](./monetization-policy.md#subscription-and-payment-validation).                                                      |
-
-```bash
-curl -X PUT "https://dev.zuplo.com/v3/metering/$BUCKET_ID/monetization-configuration" \
-  --header "Authorization: Bearer $ZAPI_KEY" \
-  --header "Content-Type: application/json" \
-  --data '{
-    "planOrder": ["free", "developer", "pro"],
-    "planSettings": {
-      "pro": { "visiblePhases": ["default"] }
-    },
-    "maxPaymentOverdueDays": 7
-  }'
-```
-
-`DELETE` removes the record entirely; `GET` on a bucket with no record returns
-the schema defaults (`multipleSubscriptionsEnabled: false`, `planOrder: []`,
-`planSettings: {}`, `maxPaymentOverdueDays: 3`).
-
-## Stripe setup and billing readiness
-
-These endpoints script the Stripe integration that the
-[Monetization Service UI](./stripe-integration.md#connecting-your-stripe-account)
-runs interactively. They live on the Zuplo developer API, so the request shape
-is documented here.
-
-### Connect a Stripe app
-
-```http
-POST /v3/metering/{bucketId}/setup/stripe
-```
-
-Installs a Stripe app on the bucket and creates the default billing profile
-linked to that app.
-
-| Field         | Type      | Description                                                                                      |
-| ------------- | --------- | ------------------------------------------------------------------------------------------------ |
-| `apiKey`      | `string`  | Stripe secret or restricted key. Required.                                                       |
-| `name`        | `string`  | Display name for the app. Required.                                                              |
-| `taxEnabled`  | `boolean` | Initial value for `workflow.tax.enabled` on the billing profile. Optional; defaults to `false`.  |
-| `taxEnforced` | `boolean` | Initial value for `workflow.tax.enforced` on the billing profile. Optional; defaults to `false`. |
-| `country`     | `string`  | ISO 3166-1 alpha-2 supplier country for the billing profile. Optional; defaults to `"US"`.       |
-
-The request fails if the key prefix does not match the bucket environment:
-
-- Working-copy or preview buckets accept `sk_test_*` or `rk_test_*`.
-- Production buckets accept `sk_live_*` or `rk_live_*`.
-
-```bash
-curl -X POST "https://dev.zuplo.com/v3/metering/$BUCKET_ID/setup/stripe" \
-  --header "Authorization: Bearer $ZAPI_KEY" \
-  --header "Content-Type: application/json" \
-  --data '{
-    "apiKey": "rk_test_...",
-    "name": "Zuplo Monetization (test)",
-    "taxEnabled": false,
-    "country": "US"
-  }'
-```
-
-### Read the connected Stripe app
-
-```http
-GET /v3/metering/{bucketId}/setup/stripe
-```
-
-Returns a summary of the connected Stripe app, the matched billing profile, and
-connection-test status. Use this to confirm the integration is wired up before
-continuing.
-
-### Add a billing profile to a Stripe app
-
-```http
-POST /v3/metering/{bucketId}/setup/stripe/{stripeAppId}/billing-profile
-```
-
-Creates an additional billing profile against an already-installed Stripe app.
-This is rarely needed — the default profile is created during initial setup. Use
-this endpoint to create per-supplier-country profiles.
-
-### Check billing readiness
-
-```http
-GET /v3/metering/{bucketId}/billing-readiness
-```
-
-Returns:
-
-```json
-{
-  "hasStripeApp": true,
-  "stripeAppId": "app_01H...",
-  "hasDefaultBillingProfile": true,
-  "defaultBillingProfileId": "bp_01H..."
-}
-```
-
-Use this in setup wizards to gate the UI on whether Stripe is connected.
-
-### Update an app
-
-```http
-PUT /v3/metering/{bucketId}/apps/{appId}
-```
-
-Replaces an app's configuration (name, description, metadata, and — for Stripe
-apps — `secretAPIKey`). The same key-prefix validation as `POST /setup/stripe`
-applies: a Stripe key must match the bucket environment.
-
 ## API Reference
 
 For complete API operations, see the API Reference documentation: