The Bridge

Add an on/off feature to what a plan includes, or rename one it already has (idempotent by feature key; other features are kept). Arguments: key (plan key), feature (feature key, e.g. "analytics") and name (what customers read, e.g. "Analytics"; defaults to the key). A plan feature is an on/off feature the plan sells; gate it with a feature flag whose rule is bridge:billing.entitlement.<featureKey> eq true, so the flag follows the plan's feature list and never names plans. Something counted (projects, API calls) is a quota instead: set_plan_quota. Use remove_plan_feature to take a feature off a plan. Returns the full plan. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Register ONE OAuth redirect (callback) URI on the Bridge app, preserving every already-registered URI — never replaces the list wholesale. The URL must be absolute http(s), e.g. https://app.example.com/auth/oauth-callback or http://localhost:5173/auth/oauth-callback for local dev. Adding a URL that is already registered succeeds as a no-op (added: false). The first URI registered on an app with no default callback also becomes its default callback. Use this when wiring a new environment or fixing a "redirect_uri mismatch" OAuth error; see get_environment_info for the currently registered list, and remove_redirect_uri to unregister one. Before writing app code that consumes this, call get_integration_guide with topic=auth and the framework the app uses.

Set up or reshape ONE subscription plan in a single call: its name, description, trial, prices, features and quotas together. Creates the plan when the key is new and updates it when it exists, in one write, so a plan is never left half-configured. A new plan needs name, at least one price and, when it charges, trial (true or false); a price above 0 needs currency unless the plan's prices already use exactly one. These are the developer's decisions: when one is missing the tool changes nothing and returns DECISION_NEEDED listing the questions to ask. prices ([{ amount, interval, currency? }]) are upserted by currency + interval and quotas ([{ metric, limit, policy, kind?, source?, priceAmount?, priceCurrency? }]) by metric, with the same rules as set_plan_price and set_plan_quota; features ([{ key, name? }], the on/off features the plan includes) are upserted by key; removePrices ([{ interval, currency? }]), removeQuotas ([metric]) and removeFeatures ([key]) remove the named ones. Anything the call does not mention is kept. Returns the full plan. The CLI's bridge plan apply --spec takes the same JSON. Call list_plan_quotas without a planKey first to reuse the metric names the app already has instead of inventing new ones. Seats: name the limit (e.g. seats), kind gauge, source membership; Bridge counts the workspace's active members, pending invites included. Enforce it where invites happen: the built-in team page with its seat-limit setting, or @RequireQuota on the app's own invite handler. Never a flag or an entitlement. Count usage once, where the action happens: ask the developer whether the action calls their server. If it does, the backend decorator (@RequireQuota) counts it. If it does not, the browser reports it (bridge.usage.report / set) with on the button; that is a complete, first-class setup. Never count one metric in both places. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Archive a subscription plan: the workspaces on it keep it and keep being billed, but nobody new can choose it — it leaves the plan picker, checkout refuses it, and its Stripe product and prices are archived. Use it to stop selling a plan that workspaces are on (delete_plan refuses those). archived: false brings an archived plan back. Returns how many workspaces are on it. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Remove a scheduled state transition from a feature flag, by KEY. The flag keeps whatever state it is in now — clearing a schedule cancels the pending change, it does not roll anything back. Safe to call when no schedule is set. Fails with FLAG_NOT_FOUND when no flag has the given key. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses.

Store the app's Stripe API credentials so billing (checkout, subscriptions, the billing portal) works. Arguments: secretKey (the Stripe SECRET key, "sk_live_..." or "sk_test_...") and publishableKey (the Stripe publishable key, "pk_live_..." or "pk_test_..."). Both are found in the Stripe dashboard under Developers > API keys. Ask the user for these — never invent or guess a key. Returns { connected, webhookConfigured } and nothing else: the keys are never echoed back. connected=false means the credentials were stored but Stripe did not confirm them, so re-check the keys. webhookConfigured=false means Stripe events will not reach Bridge; see get_stripe_status. Use get_stripe_status to check the current state without writing. IMPORTANT: this stores the credentials but does NOT enable payments — Stripe stays switched off until setup_payments turns it on. For first-time setup prefer setup_payments, which does both. Use this only to rotate keys on an app where payments are already enabled. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Create a new API token for the Bridge app. Arguments: name (required — how the token is identified and revoked later, so make it descriptive and unique), privileges (array of privilege KEYS; defaults to none, and a token with no privileges can do very little — grant only what the consumer needs), expireAt (ISO 8601 date-time; omit for no expiry). The plaintext token is returned ONCE in the response and cannot be retrieved again — hand it to the user and never write it into source code or a committed file. Use revoke_api_token to destroy one. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Create a new Bridge app in the workspace this connection belongs to, exactly as the dashboard would. Returns its id. It does NOT become the default: pass its id as app, or call use_app. Use a new app for a new environment or product rather than repurposing an existing one — an existing app may have live users, email links and billing attached. Only a connection approved for the whole workspace can create apps. A new app has no sign-in callback address: pass callbackUrl with the one the project uses (its real port), or add it later with add_redirect_uri — until then sign-in fails with NBLOCKS_NO_CALLBACK_URI. Before writing app code that signs users in to the new app, call get_integration_guide with topic=auth and the framework the app uses.

Create a new feature flag. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses. The result carries warnings when the flag cannot mean what it looks like — switched on while its onValue is false, or a rule on a plan or role the app does not have. A warning never blocks the write; read it and fix the flag. Every gate in app code is a flag: flags are the standard way to control a route, an API endpoint, a feature or a piece of code. A feature a plan sells is also listed on the plan, and the flag's rule points at bridge:billing.entitlement.. Access by who someone is is a rule on a privilege (preferred) or a role; app code never reads a role, privileges, the plan or a plan feature itself. Numbers are plan quotas, not flags; permission on one specific record stays in app code. Full rule: get_integration_guide topic=fit-together. Arguments: key (required — the identifier code reads, e.g. "beta-ui"), description, state (off | on | on-with-rule; defaults to off), valueType (boolean | string | number | json; defaults to boolean), onValue / offValue (the typed values returned in the on / off states — real JSON values, e.g. true, "variant-b", 42, or an object), and rule for state=on-with-rule. A rule is ordered branches of AND-ed conditions, first match wins, else otherwiseValue; the rule argument has the full shape and examples. A feature a plan sells is listed on the plan (add_plan_feature) and the rule points at that list, never at plan names. For who someone is, prefer a privilege rule over a role rule on the role KEY; read the app's real roles with list_roles first. The same rule gives the same answer in the browser and on the NestJS backend. Use update_feature_flag to change an existing flag, and toggle_feature_flag for a quick on/off switch by key.

Create a new subscription plan with its first recurring price. Arguments: key (required — stable identifier used in code and billing, e.g. "pro"; flag rules point at the plan's features, not its key), name (required — the display name), amount + interval (the first price; amount 0 for a free or contact-sales tier: a plan with no price can never be assigned to a workspace), currency (ISO code) and trial (true or false), with trialDays when trial is true, and description. Price, interval, currency and trial are the developer's decisions: when one is missing (currency and trial are only needed when amount is above 0) the tool changes nothing and returns DECISION_NEEDED listing the questions to ask. Add more prices (e.g. yearly) with set_plan_price and usage quotas with set_plan_quota, or use apply_plan to create a plan with all its prices and quotas in one call; update_plan changes name, description and trial later. Returns the full plan. Count usage once, where the action happens: ask the developer whether the action calls their server. If it does, the backend decorator (@RequireQuota) counts it. If it does not, the browser reports it (bridge.usage.report / set) with on the button; that is a complete, first-class setup. Never count one metric in both places. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Create a new privilege: a named permission roles can grant. Arguments: key (permanent, upper-case, e.g. "REPORTS_VIEW" — code and flag rules compare it exactly) and description (what it allows). A new privilege is granted by no role until you add it with update_role (pass the full privilege list) or create_role. Same as bridge privilege create. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Create a new access role. Arguments: name (display name), key (stable identifier code references, e.g. "ADMIN"), description, privileges (list of privilege KEYS the role grants — see list_roles for the keys existing roles use), and isDefault (make this the role assigned to people added to a workspace without a role named; default false). Use update_role to change an existing role and set_default_role to make an existing role the default. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Make a tracking short link (e.g. https://thebridge.dev/tt/code8) to put in a social post or video description. A click is counted (no cookie, no IP) and forwarded to the destination with utm tags (utm_source = platform, utm_medium, utm_content = format, utm_campaign = label) and ref=. Arguments: destination (required; the https page the link opens), source (where the link will be posted: the post or channel URL, a platform name such as "TikTok", or free text such as "an Instagram reel"; the platform and format are detected from it), label (the content's name, e.g. "passkeys video"). Use the SAME label for the same content on another channel: the link then shares the content's code (thebridge.dev/yt/code8 and /tt/code8). If the user did not say where the link will be posted, ask them before calling; without a source the link is filed as "other" (thebridge.dev/go/…). Returns the short link, its code, and the detected platform and format. The link works at once. list_short_links shows the workspace's links with click counts.

Create a new tenant (workspace/customer account) in the Bridge app. Arguments: ownerEmail (required — the owner user is created and invited by the platform), name (tenant display name), plan (a plan KEY from list_plans, e.g. "pro" — note this is the key, the same value feature-flag rules compare), locale (ISO 639-1, e.g. "en"). Use invite_user to add more users to the tenant afterwards. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Create a test user to prove sign-in works: a generated email and password, in its own workspace named "[test] …" and marked as a test fixture (no plan, no emails sent). Returns the email and the generated password; pass them to verify_login. Test-user sign-ins never count as real ones. On a production Bridge environment, or when the app's Stripe keys are live, the call is refused unless confirm repeats the app's exact name — ask the user first. Same as bridge test-user create. Before writing app code that signs users in, call get_integration_guide with topic=auth and the framework the app uses.

When someone cannot sign in: their recent sign-in attempts, newest first, each failure with the reason (WRONG_PASSWORD, USER_NOT_FOUND, NO_PASSWORD_SET, NO_ACTIVE_WORKSPACE, MFA_CODE_INVALID, ORIGIN_NOT_ALLOWED, …), a plain explanation and the fix — plus whether the user exists, has a password and has an active workspace. The reasons are for the app's admins only; the person signing in is always just told the credentials were wrong. Same as bridge event auth-attempts. To reproduce a sign-in yourself, use verify_login.

Permanently delete a feature flag by its KEY. THIS IS IRREVERSIBLE — the flag, its targeting rule, its schedule and its evaluation history are gone, and any app code still calling the key silently falls back to its hard-coded default. There is no undo and no archive. Requires confirmation: pass confirm set to the exact flag key, and only after the user has explicitly asked for the deletion — do not supply it on your own initiative. Prefer toggle_feature_flag to switch a flag off, which is reversible and is what "turn this off" almost always means. To retire a flag properly, remove the code that reads it first, then delete. dryRun: true previews it first — the flag's state, rule and schedule and what deleting it does — without deleting anything or needing confirm. Fails with FLAG_NOT_FOUND when no flag has the given key. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses.

Delete a subscription plan that NO workspace is on; its Stripe product and prices are archived. A plan workspaces are on is REFUSED with PLAN_IN_USE and nothing changes: tell the user how many workspaces are on it and offer the choices — archive_plan (they keep it, nobody new can choose it), or move them with set_tenant_plan, or delete them with delete_tenant, and then delete the plan. REQUIRES CONFIRMATION: call again with confirm set to the exact plan key, only after the user has explicitly agreed — never supply it on your own initiative. dryRun: true previews it first (delete or refuse, and which workspaces are on the plan) without changing anything or needing confirm. Fails with PLAN_NOT_FOUND when no plan has that key. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Permanently delete a privilege, addressed by its key (or id) from list_privileges. THIS IS IRREVERSIBLE — the privilege is removed from every role that grants it, so people holding those roles lose it at their next sign-in, and flag rules and app code that check its key stop matching anyone. The AUTHENTICATED privilege cannot be deleted. Requires confirmation: pass confirm set to the exact privilege key, and only after the user has explicitly asked for the deletion — do not supply it on your own initiative. To take a privilege away from one role only, use update_role instead. dryRun: true previews it first — the privilege and the roles that grant it — without deleting anything or needing confirm. Fails with PRIVILEGE_NOT_FOUND when nothing matches. Same as bridge privilege delete. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Permanently delete an access role, addressed by its key (or id) from list_roles. THIS IS IRREVERSIBLE. People who hold the role are NOT moved to another one — reassign them first with update_user, or they are left holding a role that no longer exists. Flag rules and app code that check the role key stop matching anyone. The default role and the OWNER role cannot be deleted: to delete the current default, make another role the default with set_default_role first. Requires confirmation: pass confirm set to the exact role key, and only after the user has explicitly asked for the deletion — do not supply it on your own initiative. dryRun: true previews it first — the role and the privileges it grants — without deleting anything or needing confirm. Fails with ROLE_NOT_FOUND when nothing matches. Same as bridge role delete. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Delete a tenant and everything scoped to it (its users, subscription and data). This is IRREVERSIBLE and REQUIRES CONFIRMATION: resolve the tenant first, then call again with confirm set to the exact tenant name. Only do so after the user has explicitly agreed to the deletion — never supply the confirmation on your own initiative. Fails without deleting anything when the name matches no tenant (TENANT_NOT_FOUND), matches several (TENANT_AMBIGUOUS), or the confirmation does not match. To remove a single person instead of the whole workspace use remove_user. dryRun: true previews it first — the members, which of them lose their login account, and the side effects — without deleting anything or needing confirm. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Check a project's Bridge configuration against the real app and return every concrete difference with its fix: wrong app id, a base URL pointing at another Bridge environment, a callback URL that is not a registered redirect URI, an origin that is not allowed, a missing variable the framework needs, an API key in a browser-bundled variable (VITE_*, NEXT_PUBLIC_*), and whether this environment serves its signing keys. Pass only the Bridge-related variables from the project's .env files. For any secret (BRIDGE_API_KEY or anything named *_KEY / *_SECRET) send a placeholder such as "" — never the real value; only its presence and placement are checked. bridge diagnose does the same from a shell and reads the .env files itself. get_environment_info lists the values each variable should hold; add_redirect_uri and update_app fix what it finds.

Dry-run a feature flag against a synthetic context and explain the verdict. Nothing is written and no eval is recorded — this evaluates the live flag config in-process with the exact evaluator the server and the SDKs use, so the answer matches what the app would see. Use it to check targeting you just wrote before shipping code that depends on it. Arguments: key (required), identity (the stable id the rule buckets on — a user id, tenant id or device key), and attributes (a flat map of the values the rule tests, e.g. { "bridge:billing.entitlement.analytics": true, "privileges": ["REPORTS_VIEW"] }; dotted paths and nested objects both resolve, and roles are their KEYS). Returns the resolved value plus an explanation: which branch matched (or that none did), whether a rolloutPct bucket applied, and the bucket number. IMPORTANT: a rule with rolloutPct < 100 requires an identity; called without one the evaluator returns the safe otherwiseValue instead of bucketing, which is reported explicitly rather than looking like a targeting failure. warnings also names settings that cannot mean what they look like: switched on while the onValue is false, or a rule on a plan or role the app does not have. get_flag shows the rule being evaluated; update_feature_flag changes it.

Export every feature flag as a portable "flags as code" bundle: { version: 1, flags: [...] }, sorted by key. Each entry carries key, description, state, valueType, onValue/offValue, the full targeting rule and any schedule — everything import_feature_flags needs, and nothing environment-specific (no ids, no eval counters), so the bundle can be committed to a repo or promoted from one environment to another. The format matches the Bridge CLI's bridge flag export, so bundles move between the two. Use list_feature_flags instead when you just want to read the current setup, since that keeps the ids.

Read the full Bridge app configuration: name, URLs, enabled login methods, registered redirect URIs, default role, plan/billing setup and other app-level settings. Call this first to understand how the app is configured before changing anything or diagnosing auth issues. Narrower reads: get_auth_config for login methods, get_environment_info for the values a project's .env needs, and get_setup_status for what is still missing before going live. Change settings with update_app.

Read the Bridge app's login/auth configuration: which login methods are enabled (password — always available on Bridge, magic link, passkeys, MFA as a second factor, and each social provider: Google, LinkedIn, Azure AD, Apple, GitHub, Facebook) plus the access/refresh token TTLs as configured on the app. Use this when building or debugging login UI/flows — e.g. deciding which login buttons to render or why a provider button is missing. Narrower and login-focused compared to get_app, which returns the entire app object; for redirect URIs and env-var wiring use get_environment_info. Same list as bridge auth methods list.

Read the current branding of the Bridge-hosted auth pages (login, signup, reset password). Returns the applied values — bgColor, textColor, linkColor, primaryButtonBgColor, primaryButtonTextColor, tertiaryButtonBgColor, tertiaryButtonTextColor, fontFamily, borderRadius, boxShadow — plus customCss (whether a custom stylesheet is uploaded) and defaultValues (the Bridge defaults, so you can tell what has actually been customized). Read this before calling update_branding so you keep the values you are not changing.

Read the practical wiring facts needed to configure a project against this Bridge app: the app id, Bridge API base URL, registered OAuth redirect URIs, default callback URI, allowed CORS origins, and the canonical env-var NAMES each framework reads (with suggested values where derivable). Use this when scaffolding a project, writing a .env file, or debugging a redirect/CORS mismatch. Env-var names are the ones documented by the Bridge framework plugins and CLI guides: Vite frontends use VITE_BRIDGE_*, Next.js uses NEXT_PUBLIC_BRIDGE_APP_ID, server SDKs use BRIDGE_APP_ID (+ BRIDGE_API_KEY where a management/API key is needed); bridge-angular has no env-var convention (configuration is code-based). The API base URL is the one of the Bridge environment this server runs in, which is the one this app lives in. For login-method setup use get_auth_config; for the full app object use get_app.

Read one feature flag by its KEY (e.g. "beta-ui") with everything about it: id, key, description, state (off | on | on-with-rule), valueType (boolean | string | number | json), onValue / offValue, the targeting rule, any scheduled state transition, and where the flag came from (source, triagedAt). Evaluation counts are not available through the API. Use this to confirm a flag key and its targeting before relying on it in code; list_feature_flags shows every flag. Fails with FLAG_NOT_FOUND when no flag has the given key. The result carries warnings when the flag cannot mean what it looks like — switched on while its onValue is false, or a rule on a plan or role the app does not have. A warning never blocks the write; read it and fix the flag.

Read the Bridge integration guide for a topic — the supported, opinionated way to consume Bridge from application code. Call this BEFORE writing or changing app code that reads a feature flag, renders billing or team UI, or wires authentication, and before hand-rolling anything against the SDK: the SDKs ship declarative surfaces for these cases (components, route guards, decorators) and reimplementing them against SDK internals is the most common integration mistake. Per-framework topics (framework REQUIRED): integration (first-time setup) | auth | feature-flags | billing | team | branding. Framework-agnostic MASTER topics (framework is IGNORED — omit it): master, the end-to-end auth integration prompt served by bridge guide, which orchestrates project discovery and then routes to the per-framework guides; flags-master and billing-master, the same orchestration for a flags-only or billing-only integration; mechanisms, how limits, upgrades and customization work; orientation, what Bridge does (the same map get_started returns); fit-together, how roles, plans, limits and flags fit together; integration-success, the message to show the developer when an integration is done. Before setting up flags, roles, plans or limits, read topic=fit-together. Start at topic=master when integrating Bridge into a project for the first time. framework: svelte | react | angular | nextjs | nestjs | express — pass the one the target app actually uses; this server cannot detect it. Returns the guide as markdown plus its source URL. Guidance is a default, not a mandate — follow the user's stated preference when it differs.

Read one subscription plan by its KEY (e.g. "pro"), including prices and per-metric usage quotas. Returns key, name, description, trial settings (trial, trialDays), prices (amount, currency, recurrence interval) and quotas (metric, limit, hard vs metered policy, counter vs gauge kind, per-unit pricing for metered quotas). Use list_plans to discover the keys, list_plan_quotas when you only need the quota array, and get_stripe_status to check that billing is actually wired up. Fails with PLAN_NOT_FOUND when no plan has the given key.

Read one access role by its KEY (e.g. "ADMIN"), including the full list of privileges it grants. Returns key, name, description, isDefault (whether new users get this role) and privileges (privilege key + description). Use this to confirm a role key and its privilege keys before gating a route or component on them; list_roles shows every role. Fails with ROLE_NOT_FOUND when no role has the given key.

Report the Bridge MCP server version and how many tools it currently exposes. Your own tool list is a snapshot from when this session connected and may be stale. The surest sign is the bridge-catalogue: line every Bridge result ends with: if it differs from the catalogue your server instructions name, Bridge was updated and the user should reconnect. toolCount is a second check: if the server exposes more tools than you can see, tell the user to reconnect rather than concluding a capability is missing. Takes no arguments and changes nothing. For what Bridge does, call get_started; for which app this connection acts on, list_apps.

Readiness checklist for this app: each item (redirect URIs, default callback, allowed origins, UI URL, sign-in methods and SSO credentials, email sender, Stripe, plans, first real sign-in) says configured, missing or attention, with the next step for each, plus productionNeeds: what must still change before real users arrive. Sign-ins by test users never count as the first real one. Same as bridge setup status. To prove sign-in works, create_test_user then verify_login.

Start here. What The Bridge does, as a short map to relay to the developer: login, teams and workspaces, roles, payments and plans, feature control, look and feel, going live — each with the question to ask them next and the decision guide that follows it (bridge://guides/decisions/). Call it when you are new to Bridge, when the developer asks what Bridge can do, or before choosing which setup to start. Then read the app as it is today with get_app and get_setup_status. Same content as get_integration_guide topic=orientation. Before setting up flags, roles, plans or limits, read get_integration_guide topic=fit-together. Takes no arguments and changes nothing.

Check whether Stripe is connected to the Bridge app and whether its Stripe webhook works. Returns { connected, webhookConfigured, lastWebhookAt, lastWebhookRejectedAt, lastWebhookRejectionReason, webhookRejectionStreak, webhookRejectionsSustained, setupStatus, setupError }. connected=true means the app has stored Stripe keys and can run checkout, subscriptions and billing portal flows. webhookConfigured=false, setupStatus="failed", or webhookRejectionsSustained=true (rejections in several separate minutes, newer than lastWebhookAt; a single rejection is not a problem) means Stripe events (subscription changes, cancellations, payment failures) are NOT reaching Bridge: checkout still works, but those changes will not sync. To repair, call setup_payments again with the same keys (it re-runs setup and replaces the webhook endpoint), or use "Repair webhook" in the payment settings of the Bridge dashboard. Call this before assuming billing works; if connected is false, use setup_payments to supply the keys. For the plans and prices themselves use list_plans. Never returns a key or secret.

Get one tenant by its NAME (as shown by list_tenants; a tenant id is also accepted when the name matches nothing). Returns the full tenant record — plan, locale, logo, mfa, payment status, trial, onboarded, owner and metadata. Fails with TENANT_NOT_FOUND when no tenant carries the name, and with TENANT_AMBIGUOUS when several do.

Get one user of a tenant by EMAIL. Arguments: tenantName (the tenant NAME from list_tenants), email (the user, as shown by list_users). Returns the full user record — role, enabled, onboarded, teams, custom params and the tenant it belongs to. Fails with USER_NOT_FOUND when nobody in the tenant has that email, and USER_AMBIGUOUS when more than one record matches.

Apply a "flags as code" bundle: creates flags that do not exist and updates the ones that do, matched by key. Pass the flags array from export_feature_flags (or from the CLI's bridge flag export — same format). Each rule is validated with the same validator create_feature_flag uses, and the whole payload is checked before anything is written, so a bad rule fails the import instead of half-applying it. Set dryRun: true to see exactly what would be created, updated and left alone — including which fields differ — without touching anything; do that first when importing a bundle you did not just export. This tool NEVER deletes: flags that exist remotely but are absent from the bundle are reported as extraneous for you to remove deliberately with delete_feature_flag. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses.

Invite a person into a tenant (a customer workspace) by email: Bridge creates the user and sends the invitation. Arguments: tenantName (the tenant NAME from list_tenants, like the other user tools) or tenantId (its id, e.g. from create_tenant), email (the invitee), role (a role KEY from list_roles, e.g. "ADMIN"), firstName, lastName. The role is the developer's decision: without it the tool invites nobody and returns DECISION_NEEDED offering the app's role keys, never the app's default role silently. Returns the new user. Use create_tenant first when the tenant does not exist yet, and update_user to change the role of someone already in it. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

List every API token issued for the Bridge app. Each record includes: id, name, the granted privilege keys, the tenant it is scoped to (when any), expireAt, lastUsedAt and createdAt. The token secrets themselves are NOT returned — they are shown only once, by create_api_token. Use this to check which privileges a token carries (notably whether it may perform destructive operations) and to find the token name revoke_api_token takes.

List the Bridge apps this connection can work on, with their ids. current: true marks the app a call acts on when it names none. A connection approved for the whole workspace sees every app the workspace owns, including ones created after connecting; a single-app connection sees its one app. Pass an id as the app argument of any other tool to act on that app for one call, or call use_app to change the default.

Query the Bridge app event log — signups, logins, tenant and subscription lifecycle events. Each event has: id, type, tenantId, userId, data (the event payload) and createdAt. All arguments are optional filters: type (exact event type), tenantName (the workspace/tenant NAME — resolved to its id for you), since (a duration like "24h" or "7d", or an ISO date) and limit (max results). Use this to debug what actually happened — e.g. whether a webhook fired or a signup completed — rather than inferring it from state. Fails with TENANT_NOT_FOUND when tenantName matches no tenant (list_tenants shows the names). For why one person cannot sign in, debug_auth_issue explains each failed attempt.

List every feature flag in the Bridge app with its full targeting rules and state. Each flag includes: key, description, lifecycle state (on/off/conditional), value type and on/off values, the targeting rule tree, any scheduled state transition, and where the flag came from (source), plus warnings on any flag that cannot mean what it looks like. Use this when working with flags — verifying a flag key exists before referencing it in code, or inspecting targeting before relying on a flag. For app-level auth/config use get_app or get_auth_config instead; for project wiring use get_environment_info. Every gate in app code is a flag: flags are the standard way to control a route, an API endpoint, a feature or a piece of code. A feature a plan sells is also listed on the plan, and the flag's rule points at bridge:billing.entitlement.. Access by who someone is is a rule on a privilege (preferred) or a role; app code never reads a role, privileges, the plan or a plan feature itself. Numbers are plan quotas, not flags; permission on one specific record stays in app code. Full rule: get_integration_guide topic=fit-together.

List usage-quota metrics with their kind, so your code reports against the exact metric names the plans use instead of guessing them. With planKey (e.g. "pro"): that plan's quotas. Without planKey: every metric configured on any plan, once each, with the plans that limit it. Each quota has: metric (the key your code reports against, e.g. "num.clicks"), kind ("counter" = summed per billing period and reset each period; "gauge" = an absolute value the app sets, never reset — If deleting it frees room, it's a gauge and your app counts it; if it happened, it's a counter and Bridge counts it.), limit (integer; 0 means pure per-unit metered billing from the first unit), policy ("hard" = the cap blocks, "metered" = overage is billed), for metered quotas pricing { amount, currency }, source ("membership" when Bridge counts the workspace's active members, e.g. an app's seats limit; absent when the app reports the metric), and reportWith — how the app keeps the metric current. Use this when wiring quota checks or usage reporting; set_plan_quota changes one. Fails with PLAN_NOT_FOUND when no plan has the given key.

List every subscription plan in the Bridge app, with prices, features AND quota properties. Each plan includes: key, name, description, trial settings (trial, trialDays), prices (amount, currency, recurrence interval), features (the on/off features the plan includes, [{ key, name }]) and per-metric usage quotas (metric, limit, hard-cap vs metered policy, counter vs gauge kind, source "membership" when Bridge counts the workspace's active members (seats), and per-unit pricing for metered quotas). Use this for billing, entitlement and quota questions — e.g. which plan key to reference in code, what a plan includes, or what limits a plan enforces. Change a plan's features with add_plan_feature / remove_plan_feature / set_plan_features. To set up or reshape a plan (prices, quotas, trial) in one call use apply_plan. For whether Stripe/payments are enabled at the app level, use get_app. A plan with archived: true was removed while workspaces were on it: they keep it, nobody new can choose it. Remove a plan with delete_plan.

List every privilege defined for the Bridge app: id, key and description. Privileges are what roles are built from; this also lists privileges no role grants yet. list_roles shows which privileges each role grants. Use this before create_role / update_role, before gating a flag rule on a privilege, or to find the key for update_privilege or delete_privilege. Same as bridge privilege list. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL.

List the OAuth redirect (callback) URIs registered on the Bridge app. Read-only. Call this when diagnosing a "redirect_uri mismatch" login failure — the URL your app sends must appear here EXACTLY, including scheme, port and path. Use add_redirect_uri to register one and remove_redirect_uri to unregister one; both preserve the rest of the list. Before writing app code that consumes this, call get_integration_guide with topic=auth and the framework the app uses.

List every access role in the Bridge app with its privileges. Each role includes: id, key, name, description, whether it is the default role for new users, and the privilege KEYS it grants; each privilege's description appears once, in the top-level privileges map (key -> description). The roles a new app starts with (Owner, Admin, Member) are a default suggestion the developer can rename, re-scope or replace: read what each role grants here rather than assuming it from its name. Use this before writing a flag rule that targets a privilege or role, when checking which role to assign a user, or when verifying a privilege key exists. For login-method configuration use get_auth_config; for the whole app object use get_app. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL.

List this workspace's tracking short links, newest first: short link, code, channel, detected platform and format, label, destination, and click counts (clicks by people, and botClicks by link previewers and scripts, counted apart). Links that share a code are the same content on different channels. Use create_short_link to make one.

List every tenant (workspace/customer account) in the Bridge app. Each tenant includes: id, name, plan key, locale, logo, mfa, payment status, trial state, onboarded flag, the signup owner and createdAt. Use this to discover tenant names before calling get_tenant, update_tenant, delete_tenant or any of the user tools — those address tenants by NAME, not by id. For the users inside a tenant use list_users.

List the users of one tenant, addressed by tenant NAME (use list_tenants to find it). Each user includes: id, email, username, first/last name, role key, enabled, onboarded, teams, createdAt, lastSeen (any account activity, NOT a login), lastSignIn (account-wide) and lastWorkspaceSignIn (sign-in to THIS workspace). Use this to discover the email addresses the other user tools take. Fails with TENANT_NOT_FOUND or TENANT_AMBIGUOUS when the tenant name does not resolve to exactly one tenant.

Take an on/off feature off a plan by its feature key; other features are kept. Workspaces on the plan lose the entitlement, so a flag gated on bridge:billing.entitlement.<featureKey> turns off for them. Fails with FEATURE_NOT_FOUND when the plan does not include it. Use add_plan_feature to add one and list_plans to see every plan's features. Returns the full plan. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Remove a recurring price from a plan, identified by interval (day | week | month | year) and currency (default USD). Fails with PRICE_NOT_FOUND when the plan has no price for that currency + interval; other prices are preserved. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Remove a usage quota from a plan by its metric key. Fails with QUOTA_NOT_FOUND when the plan has no quota for that metric; other quotas are preserved. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Unregister ONE OAuth redirect (callback) URI from the Bridge app, preserving every other registered URI. Fails with REDIRECT_URI_NOT_REGISTERED (listing the currently registered URIs) when the exact URL is not registered — the match is exact, including scheme, port and path. Use add_redirect_uri to register one. Before writing app code that consumes this, call get_integration_guide with topic=auth and the framework the app uses.

Remove a user from a tenant, revoking their access to it. This is IRREVERSIBLE and REQUIRES CONFIRMATION: resolve the user first, then call again with confirm set to the exact email address — and only after the user has explicitly agreed to the removal. If access should merely be suspended, call update_user with enabled=false instead, which can be undone. Fails without removing anything when the tenant or email does not resolve to exactly one record, or the confirmation does not match. dryRun: true previews it first — whether their login account goes too (it does when this is their only workspace) and whether they are the last owner — without removing anything or needing confirm. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Revoke an API token by NAME, permanently disabling every client authenticating with it. This is IRREVERSIBLE — a revoked token cannot be restored, only replaced with a new one from create_api_token — and REQUIRES CONFIRMATION: list the tokens first, then call again with confirm set to the exact token name, and only after the user has explicitly agreed. Fails without revoking anything when the name matches no token (TOKEN_NOT_FOUND), matches several (TOKEN_AMBIGUOUS), or the confirmation does not match. dryRun: true previews it first — the token's privileges, when it was last used, and whether it is the token this very connection runs on — without revoking anything or needing confirm. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Scaffold a flags-only Bridge integration into an existing project — the MCP equivalent of bridge flag init. Returns everything that command produces, for YOU to write to disk: the contents of bridge-flags.config.json (app id, app name, base URL, suggested provider config, read live from this Bridge app), the install command, and the framework-specific setup guide fetched from the plugin repo that owns it. Writes nothing — neither to disk nor to the Bridge app. Call this when adding feature flags to a project for the first time; for auth or billing use get_integration_guide with topic=master or topic=billing-master instead. framework is REQUIRED: this server cannot see the caller's disk, so detect it yourself from package.json (next → nextjs, @sveltejs/kit or svelte → svelte, @nestjs/core → nestjs, @angular/core → angular, react → react, express → express; check in that order) and pass it. The returned guide is the same document get_integration_guide returns for topic=feature-flags, so there is no need to call both. Do not invent import specifiers — they differ per plugin and only the guide has the current ones.

Make an existing role the default: the role a person gets when they are added to a workspace without a role named (the first person in a workspace is always its Owner). Argument: key (a role KEY from list_roles, e.g. "MEMBER"). The previous default stops being the default. Which role is the default is the developer's decision — ask, do not pick one; read the app's real roles with list_roles first rather than assuming what a role grants from its name (in the default setup a new app defaults to MEMBER). Returns the updated role. Fails with ROLE_NOT_FOUND, listing the app's role keys, when no role has that key. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Schedule a future state transition on a feature flag, by KEY. The flag keeps its current state until the timestamp, then moves to the scheduled state. Arguments: key, at (an ISO-8601 timestamp such as 2026-09-01T09:00:00Z), and state (off | on | on-with-rule). Setting a schedule replaces any existing one; use clear_flag_schedule to remove it. This writes the scheduled transition onto the flag — it does not change the current state, so the flag behaves exactly as before until the timer fires. Fails with FLAG_NOT_FOUND when no flag has the given key. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses.

Replace the whole list of on/off features a plan includes. Arguments: key (plan key) and features ([{ key, name? }], e.g. [{ "key": "analytics", "name": "Analytics" }]); a feature the list leaves out is removed from the plan, and [] clears it. To add or remove one feature and keep the rest use add_plan_feature / remove_plan_feature. A plan feature is an on/off feature the plan sells; gate it with a feature flag whose rule is bridge:billing.entitlement.<featureKey> eq true, so the flag follows the plan's feature list and never names plans. The pricing table and the upgrade dialog read the same list. Returns the full plan. Use list_plans to see every plan's features. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Add or update a recurring price on a plan. A plan can carry several prices (e.g. monthly + yearly); each is identified by its currency + interval, and setting one is idempotent — an existing price for the same currency + interval is replaced, others are preserved. Arguments: key (plan key), amount (>= 0), interval (day | week | month | year), currency (ISO code). currency may be left out when the plan's prices all use one currency — that one is used; otherwise it is the developer's decision, and the tool changes nothing and returns DECISION_NEEDED asking for it. Use remove_plan_price to delete a price. Returns the full plan. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Add or update a per-metric usage quota on a plan (idempotent by metric: an existing quota for that metric is replaced, others kept). Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses. Seats: name the limit (e.g. seats), kind gauge, source membership; Bridge counts the workspace's active members, pending invites included. Enforce it where invites happen: the built-in team page with its seat-limit setting, or @RequireQuota on the app's own invite handler. Never a flag or an entitlement. Count usage once, where the action happens: ask the developer whether the action calls their server. If it does, the backend decorator (@RequireQuota) counts it. If it does not, the browser reports it (bridge.usage.report / set) with on the button; that is a complete, first-class setup. Never count one metric in both places. limit is the included units (0 = metered from unit 1); policy ("hard" blocks at the limit; "metered" bills each unit above it and needs priceAmount > 0 per unit and a currency — priceCurrency defaults to the plan's one price currency). Hard quotas must NOT carry priceAmount. A quota is for something counted. An on/off feature the plan sells (analytics, SSO, export) belongs in the plan's features, set with add_plan_feature — not a hard quota with limit 1. kind: "counter" (default) sums events per billing period and resets (API calls, emails sent); "gauge" is an absolute value the app sets, never reset (projects, tickets, storage). If deleting it frees room, it's a gauge and your app counts it; if it happened, it's a counter and Bridge counts it. A gauge cannot be metered. source "membership" (gauge only) makes Bridge count the workspace's active members; omitting source keeps an existing gauge's, null removes it. Omitting kind keeps an existing quota's kind. list_plan_quotas shows every metric name and its kind; remove_plan_quota deletes one.

Move a tenant (workspace) to another plan, the same change as the plan picker on a workspace in the Bridge dashboard. A paid Stripe subscription is updated to the new plan's price. Use it to clear a plan before delete_plan, or to put a customer on a plan by hand. Arguments: name (the tenant), plan (the plan KEY), and optionally interval and currency to pick one of the plan's prices — without them the plan's first price is used. Fails with TENANT_NOT_FOUND, TENANT_AMBIGUOUS, PLAN_NOT_FOUND or PRICE_NOT_FOUND without changing anything. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Set the sender of the transactional email Bridge sends for the app (invitations, password resets, magic links, MFA codes). Bridge delivers all of this email through its own email provider — there is no provider, account or API key to configure, and none is accepted. Arguments (at least one): fromAddress (sender email address) and fromName (sender display name). A NEW fromAddress must be verified before it is used: Bridge sends a verification email to that address, and until the link in it is clicked, email keeps coming from the Bridge default sender — tell the user to look for it. Returns the stored sender settings; use get_app to read them back later. Before writing app code that consumes this, call get_integration_guide with topic=integration and the framework the app uses.

Connect Stripe to the Bridge app in one step: stores the Stripe API credentials AND turns payments on, so checkout, subscriptions and the billing portal start working. Arguments: stripeSecretKey (the SECRET key, "sk_live_..." or "sk_test_...") and stripePublicKey (the publishable key, "pk_live_..." or "pk_test_..."), both from the Stripe dashboard under Developers > API keys. ASK THE USER FOR THESE — never invent, guess, or reuse a key from another context. The keys are never echoed back in the result. This does NOT create any plans; use create_plan / set_plan_price for those, and list_plans to see what exists. Prefer this over connect_stripe when setting billing up from scratch: connect_stripe only stores the keys and leaves Stripe disabled. Check the returned stripeSetupStatus — "failed" means Stripe rejected the credentials or Bridge could not set up its Stripe webhook, and stripeSetupError says why. webhookConfigured=false means subscription changes, cancellations and payment failures made in Stripe will not reach Bridge; calling setup_payments again with the same keys re-runs setup and replaces the webhook endpoint. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Enable a social/enterprise SSO login provider on the Bridge app in one step: saves the provider credentials, turns the provider on, and returns the app's OAuth callback URL. Arguments: provider (google | azure | github | linkedin | facebook), clientId and clientSecret from the provider console, and tenantId (the Entra ID directory id, not a Bridge tenant) — required for azure only. Company SAML or OIDC sign-in and Sign in with Apple are not configured here: asking for them returns NOT_OFFERED_HERE naming where to do it (the Bridge dashboard). THE ACTIONABLE OUTPUT IS THE RETURNED callbackUrl: the user must register it in the provider's console (e.g. Google Cloud OAuth credentials, GitHub OAuth app settings) or logins will fail with a redirect mismatch — always surface the callbackUrl and that instruction to the user. Credentials are never echoed back. This is the ONLY way to CONFIGURE a social provider (credentials + callback URL); update_auth_methods can flip the enable flags but never saves credentials. Before writing app code that consumes this, call get_integration_guide with topic=auth and the framework the app uses.

Quick-toggle a feature flag on or off by its KEY (no id lookup needed — this tool resolves it). enabled: true sets state="on", false sets state="off". Does not touch the flag's rule, values or schedule — for those use update_feature_flag. Fails with FLAG_NOT_FOUND when no flag has the given key, and with FLAG_HAS_TARGETING when the flag is state=on-with-rule and you try to turn it on, since that would widen it from the rule's audience to everyone — use update_feature_flag explicitly for that. Every gate in app code is a flag: flags are the standard way to control a route, an API endpoint, a feature or a piece of code. A feature a plan sells is also listed on the plan, and the flag's rule points at bridge:billing.entitlement.. Access by who someone is is a rule on a privilege (preferred) or a role; app code never reads a role, privileges, the plan or a plan feature itself. Numbers are plan quotas, not flags; permission on one specific record stays in app code. Full rule: get_integration_guide topic=fit-together. The result carries warnings when the flag cannot mean what it looks like — switched on while its onValue is false, or a rule on a plan or role the app does not have. A warning never blocks the write; read it and fix the flag. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses.

Update app-level settings on the Bridge app. Only the fields you pass are changed: name (display name shown on the hosted auth pages and in emails), apiUrl (your backend's base URL), uiUrl (your frontend's base URL — used to build links in invitation and password-reset emails), webhookUrl (where Bridge POSTs platform events), defaultCallbackUri (the OAuth callback used when a login flow does not name one), allowedOrigins (CORS origins), tenantSelfSignup (whether a new user may create their own workspace instead of being invited) and paymentsAutoRedirect (force new users to pick a plan before entering the app — a billing paywall). WARNING: allowedOrigins REPLACES the entire list, so call get_app first and pass the existing origins plus the new one; the previous list is returned as previousAllowedOrigins so a mistake can be undone. Redirect URIs are NOT settable here — use add_redirect_uri / remove_redirect_uri, which preserve the rest of the list. Login methods are not settable here either — use update_auth_methods, or setup_sso for a provider with credentials. Token lifetimes: use update_password_policy. Before writing app code that consumes this, call get_integration_guide with topic=auth and the framework the app uses.

Toggle the app's login methods. Only the fields you pass are changed: mfaEnabled (MFA as a second factor), passkeysEnabled (WebAuthn passkeys), magicLinkEnabled (email magic links), and the social provider flags (googleSsoEnabled, linkedinSsoEnabled, azureAdSsoEnabled, appleSsoEnabled, githubSsoEnabled, facebookSsoEnabled). Email + password login is always available on Bridge and has no toggle. A social provider can only be switched on once its credentials are saved — otherwise Bridge refuses with SIGN_IN_CREDENTIALS_MISSING and a fix; to configure a provider end-to-end (credentials + enable + callback URL) use setup_sso. Bridge also refuses to switch off the last remaining sign-in method (LAST_SIGN_IN_METHOD). CLI: bridge auth methods enable|disable <method>. Returns the updated login-method configuration (same projection as get_auth_config). For MFA this is the same as bridge auth mfa --enabled true|false. Before writing app code that consumes this, call get_integration_guide with topic=auth and the framework the app uses.

Update the Bridge-hosted auth pages' branding (login, signup, etc.). Only the fields you pass are changed: bgColor, textColor, linkColor, primaryButtonBgColor, primaryButtonTextColor (CSS color values, e.g. "#1a1a2e"), fontFamily (CSS font-family value) and borderRadius (CSS length, e.g. "8px"). Returns the full updated branding configuration. This same record is pushed live to connected SDK clients as bridge.app.branding — before writing app code that renders a workspace logo, name or colours, call get_integration_guide with topic=branding and the framework the app uses.

Update an existing feature flag by its id (get the id from list_feature_flags). Only the fields you pass are changed. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses. The result carries warnings when the flag cannot mean what it looks like — switched on while its onValue is false, or a rule on a plan or role the app does not have. A warning never blocks the write; read it and fix the flag. Every gate in app code is a flag: flags are the standard way to control a route, an API endpoint, a feature or a piece of code. A feature a plan sells is also listed on the plan, and the flag's rule points at bridge:billing.entitlement.. Access by who someone is is a rule on a privilege (preferred) or a role; app code never reads a role, privileges, the plan or a plan feature itself. Numbers are plan quotas, not flags; permission on one specific record stays in app code. Full rule: get_integration_guide topic=fit-together. Fields: key, description, state (off | on | on-with-rule), valueType (boolean | string | number | json), onValue / offValue (typed JSON values), rule (replaces the whole rule), clearRule: true to remove the rule entirely. A rule is ordered branches of AND-ed conditions, first match wins, else otherwiseValue; the rule argument has the full shape and examples. A feature a plan sells is listed on the plan (add_plan_feature) and the rule points at that list, never at plan names. For who someone is, prefer a privilege rule over a role rule on the role KEY; read the app's real roles with list_roles first. The same rule gives the same answer in the browser and on the NestJS backend. For a plain on/off switch prefer toggle_feature_flag, which works by key.

Set the session token lifetimes on the Bridge app: accessTokenTTL and refreshTokenTTL, both in SECONDS. Only the fields you pass are changed. IMPORTANT — despite the name (kept for parity with bridge auth password-policy), this sets token TTLs and NOTHING about passwords: Bridge exposes no password-complexity, rotation or reuse policy on the management API, so if the user asked for password rules, say so instead of calling this. The access token TTL controls how often a client silently refreshes (short is safer, e.g. 900 = 15 minutes); the refresh token TTL controls how long a user stays logged in without re-authenticating (e.g. 2592000 = 30 days). Read the current values with get_auth_config. Before writing app code that consumes this, call get_integration_guide with topic=auth and the framework the app uses.

Update an existing subscription plan by its key. Only the fields you pass are changed: name (the display name; flag rules read the plan's features, never its name, so renaming never changes who a rule matches), description, trial and trialDays. Set trial=false to REMOVE a trial from a plan that has one. Prices and quotas are NOT updated here — use set_plan_price / remove_plan_price and set_plan_quota / remove_plan_quota instead. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Update a privilege, addressed by its key (or id) from list_privileges. Only the fields you pass are changed: newKey (renames it) and description. Roles that grant it keep granting it under the new key, but flag rules and app code that name the OLD key stop matching — update them too. The AUTHENTICATED privilege cannot be renamed. Same as bridge privilege update. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Update an existing access role by its id (get the id from list_roles). Only the fields you pass are changed: name, description, privileges, isDefault. NOTE: privileges REPLACES the whole privilege list — read the current list from list_roles first and pass the full desired set, or privileges not included are revoked. isDefault=true makes this the role people get when added to a workspace without a role named (the previous default stops being default); an app always has exactly one default, so to move it pass isDefault=true on the new one rather than false on the old one. set_default_role does the same by role key. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Update a tenant, addressed by its current NAME. Only the fields you pass are changed. Arguments: name (required — the tenant to update), newName (rename the tenant), locale (ISO 639-1, e.g. "en"), logo (an image URL). Fails with TENANT_NOT_FOUND or TENANT_AMBIGUOUS without changing anything. Use create_tenant to create one and delete_tenant to remove one. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Update a user of a tenant, addressed by EMAIL. Only the fields you pass are changed. Arguments: tenantName (tenant NAME), email (the user), role (a role KEY from list_roles, e.g. "ADMIN"), enabled (false disables sign-in without deleting the account — prefer this over remove_user when access should be revocable), firstName, lastName. Fails with TENANT_NOT_FOUND / TENANT_AMBIGUOUS / USER_NOT_FOUND / USER_AMBIGUOUS without changing anything. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Make an app the default for this connection: later calls that pass no app argument act on it. Takes an app id from list_apps. The choice is kept on the connection, so it applies to every session using it; pass app on a single call instead when you only need one app briefly.

Prove a sign-in works end to end: signs in for real through this Bridge environment exactly as the SDK does (from one of the app's allowed origins), exchanges the session for tokens, and verifies the access token against the published JWKS. Returns verified with the steps and evidence (key id, algorithm, issuer, audience, subject, workspace, expiry, claims checked) — never the tokens. When verified is false, failure names the reason (WRONG_PASSWORD, USER_NOT_FOUND, NO_PASSWORD_SET, NO_ACTIVE_WORKSPACE, ORIGIN_NOT_ALLOWED, MFA_REQUIRED, …) and its fix. Use the credentials from create_test_user. Same as bridge test-user verify. If sign-in works here but not in the app, the app code is the difference: call get_integration_guide with topic=auth and the framework the app uses.