@fusebase/fusebase-gate-sdk 2.3.12 → 2.3.13

package/dist/apis/AppEmbedTargetsApi.d.ts

@@ -11,7 +11,7 @@ export declare class AppEmbedTargetsApi {
     constructor(client: Client);
     /**
      * List an app's portal embeds
-     * Returns the portal pages in the organization where the given app is embedded (as an app-feature brick). One entry per page, each with the portal name, page title, and a ready-to-use page URL. Org-scoped by design (per spec); workspace-level access enforcement is portal-service's responsibility. Requires portals.read access.
+     * Returns the portal pages in the organization where the given app is embedded (as an app-feature brick or via a regular embed/iframe block pointing at the app host). One entry per page, each with the portal name, page title, a ready-to-use page URL, and a `kind` of 'app-feature' or 'iframe' (app-feature wins when a page has both). Org-scoped by design (per spec); workspace-level access enforcement is portal-service's responsibility. Requires portals.read access.
      */
     listAppPortalEmbeds(params: {
         path: {

package/dist/apis/AppEmbedTargetsApi.js

@@ -13,7 +13,7 @@ class AppEmbedTargetsApi {
     }
     /**
      * List an app's portal embeds
-     * Returns the portal pages in the organization where the given app is embedded (as an app-feature brick). One entry per page, each with the portal name, page title, and a ready-to-use page URL. Org-scoped by design (per spec); workspace-level access enforcement is portal-service's responsibility. Requires portals.read access.
+     * Returns the portal pages in the organization where the given app is embedded (as an app-feature brick or via a regular embed/iframe block pointing at the app host). One entry per page, each with the portal name, page title, a ready-to-use page URL, and a `kind` of 'app-feature' or 'iframe' (app-feature wins when a page has both). Org-scoped by design (per spec); workspace-level access enforcement is portal-service's responsibility. Requires portals.read access.
      */
     async listAppPortalEmbeds(params) {
         return this.client.request({

package/dist/types/app-embed-targets/app-embed-targets.d.ts

@@ -9,6 +9,12 @@ export interface AppPortalEmbedContract {
     };
     /** Ready-to-use URL of the portal page where the app is embedded. */
     url: string;
+    /**
+     * How the app is embedded on the page: as a first-class `app-feature` brick or
+     * via a regular `embed` (iframe) block whose `contentUrl` points at the app
+     * host. When a page matches both, `app-feature` wins (brick precedence).
+     */
+    kind: "app-feature" | "iframe";
 }
 export interface ListAppPortalEmbedsResponseContract {
     /** One entry per portal page where the app is embedded. */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusebase/fusebase-gate-sdk",
-  "version": "2.3.12",
+  "version": "2.3.13",
   "description": "TypeScript SDK for Fusebase Gate APIs - Generated from contract introspection",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",

package/release-notes/2.3.13-sdk.0.md

@@ -0,0 +1,102 @@
+# Release Notes 2.3.13-sdk.0
+
+- Current ref: `HEAD`
+- Previous tag: `v2.3.12`
+- Generated at: 2026-06-29T09:24:21.148Z
+
+## Included Drafts
+
+- `docs/release-notes/2026-06-16-bulk-invite-to-portal.md` - Bulk invite users to a portal
+- `docs/release-notes/2026-06-29-app-portal-embeds-iframe-kind.md` - App portal embeds — detect iframe embeds, add `kind`
+
+## Summary
+
+### Bulk invite users to a portal
+
+Gate exposes `POST /:orgId/portals/:portalId/invite/bulk` (`bulkInviteToPortal`) to invite many users to a single portal in one request, replacing N sequential `inviteToPortal` calls. Invites run with bounded concurrency (default 5, max 5); the rest are queued. Portal discovery (`listPortals`/`getPortal`) runs once for the whole batch. An optional `background` mode returns immediately without blocking the caller.
+
+### App portal embeds — detect iframe embeds, add `kind`
+
+Extends `listAppPortalEmbeds` to also report portal pages where the app is embedded
+via a regular `embed` (iframe) block whose `contentUrl` points at the app host, in
+addition to the existing `app-feature` brick embeds. Every entry now carries a
+`kind` discriminator. Detection works for all consumers, including the in-app
+runtime app-token path.
+
+
+## API / SDK Changes
+
+### Bulk invite users to a portal
+
+- Added `bulkInviteToPortal` operation and `PortalsApi.bulkInviteToPortal` SDK client method.
+- Request: `invitations[]` (each item matches `inviteToPortal`: `email` required; optional `fullName`, `orgRole`, `workspaceRole`, `isFullAccess`), optional `concurrency` (1..5, default 5), optional `background` (default false).
+- Response: `total`, `status` (`completed` | `processing`). For `completed`: `succeeded`, `failed`, `results[]` (`{ email, status, magicLink?, url?, userId?, error? }`). For `processing`: `accepted`.
+- Per-invitation `orgRole`/`isFullAccess` semantics are identical to `inviteToPortal` (shared `invitePortalUser` helper).
+- Permission: `portals.manage` with org-scoped authz (same as `inviteToPortal`).
+- MCP: `bulkInviteToPortal` is MCP-visible under the `portals` prompt group; the prompt now documents batching, concurrency, background mode, and the client access-clarification rule.
+
+### App portal embeds — detect iframe embeds, add `kind`
+
+- `ListAppPortalEmbedsResponse` entries gain `kind: 'app-feature' | 'iframe'`
+  (additive, non-breaking).
+- `listAppPortalEmbeds` now merges two portal-service searches:
+  - existing brick search (`blockType=flexible`, `brickType=app-feature`,
+    `brickMatch=featureId:<appId>`) → `kind: 'app-feature'`.
+  - new iframe search (`blockType=embed`, `attrContains=contentUrl:<host>` per
+    resolved host) → `kind: 'iframe'`.
+- Host(s) resolved via nimbus-ai `apiGetAppByGlobalId` using a secret-only
+  ("visitor") header (no caller user id), so the app-token runtime path works too.
+  Takes the host of `url` and, when set, of `customDomainFqdn` (deduped).
+- Merge is per page with brick precedence: a page matched by both stays
+  `app-feature`.
+- Graceful degrade: if host resolution yields nothing (app not found / unpublished
+  / nimbus-ai unreachable), the iframe search is skipped and brick embeds are
+  returned normally — the op never fails on this.
+
+
+## Consumer Impact
+
+### Bulk invite users to a portal
+
+- App agents inviting several clients can issue one call instead of N blocking sequential requests.
+- Single `inviteToPortal` is unchanged; behavior and response shape are preserved.
+- Failures are isolated per invitee in `completed` mode — a single bad invite does not fail the batch.
+
+### App portal embeds — detect iframe embeds, add `kind`
+
+- public-api / CLI / frontend receive the new `kind` field; downstream consumers
+  pass it through without behavioral or visual differentiation for now.
+- Requires `npm run build:sdk` to publish the additive `kind` field and the updated
+  op description.
+
+
+## Verification
+
+### Bulk invite users to a portal
+
+- `npm test -- tests/unit/portals-bulk-invite-controller.test.ts tests/unit/concurrency.test.ts tests/unit/portals-controller.test.ts`
+- `npm run build`
+- `npm run build:sdk`
+- `npm run mcp:skills:generate` (validate blocked locally: `skills-ref` Python module unavailable in this environment)
+
+### App portal embeds — detect iframe embeds, add `kind`
+
+- `eslint` and `tsc --noEmit` clean on the changed files (whole-project tsc: 0
+  errors).
+- Runtime (user): embed an app via a regular `embed` block (managed or custom host,
+  with path/query) → page appears with `kind: 'iframe'`; brick + iframe on the same
+  page → one `app-feature` row; nimbus-ai down / app unpublished → brick results
+  returned normally. Works for internal-user and app-token auth.
+
+
+## Follow-ups
+
+### Bulk invite users to a portal
+
+- Background mode is fire-and-forget within the request pod; if durable retry/observability is later required, move bulk processing to a worker/queue.
+
+### App portal embeds — detect iframe embeds, add `kind`
+
+- Regenerate + publish the SDK (`npm run build:sdk` / `build:sdk:push`); note the
+  version for the M3A (public-api) and M4A (nx-frontend) pin bumps.
+- M3A/M4A/M5A pass `kind` through unchanged.

package/release-notes/2.3.13.md

@@ -0,0 +1,9 @@
+# Release Notes 2.3.13
+
+- Current ref: `HEAD`
+- Previous tag: `v2.3.13`
+- Generated at: 2026-06-29T11:00:58.685Z
+
+## Included Drafts
+
+- None

package/release-notes/latest.md

@@ -1,53 +1,9 @@
-# Release Notes 2.3.12
+# Release Notes 2.3.13
 
 - Current ref: `HEAD`
-- Previous tag: `v2.3.12`
-- Generated at: 2026-06-29T08:59:27.274Z
+- Previous tag: `v2.3.13`
+- Generated at: 2026-06-29T11:00:58.685Z
 
 ## Included Drafts
 
-- `docs/release-notes/2026-06-16-bulk-invite-to-portal.md` - Bulk invite users to a portal
-
-## Summary
-
-### Bulk invite users to a portal
-
-Gate exposes `POST /:orgId/portals/:portalId/invite/bulk` (`bulkInviteToPortal`) to invite many users to a single portal in one request, replacing N sequential `inviteToPortal` calls. Invites run with bounded concurrency (default 5, max 5); the rest are queued. Portal discovery (`listPortals`/`getPortal`) runs once for the whole batch. An optional `background` mode returns immediately without blocking the caller.
-
-
-## API / SDK Changes
-
-### Bulk invite users to a portal
-
-- Added `bulkInviteToPortal` operation and `PortalsApi.bulkInviteToPortal` SDK client method.
-- Request: `invitations[]` (each item matches `inviteToPortal`: `email` required; optional `fullName`, `orgRole`, `workspaceRole`, `isFullAccess`), optional `concurrency` (1..5, default 5), optional `background` (default false).
-- Response: `total`, `status` (`completed` | `processing`). For `completed`: `succeeded`, `failed`, `results[]` (`{ email, status, magicLink?, url?, userId?, error? }`). For `processing`: `accepted`.
-- Per-invitation `orgRole`/`isFullAccess` semantics are identical to `inviteToPortal` (shared `invitePortalUser` helper).
-- Permission: `portals.manage` with org-scoped authz (same as `inviteToPortal`).
-- MCP: `bulkInviteToPortal` is MCP-visible under the `portals` prompt group; the prompt now documents batching, concurrency, background mode, and the client access-clarification rule.
-
-
-## Consumer Impact
-
-### Bulk invite users to a portal
-
-- App agents inviting several clients can issue one call instead of N blocking sequential requests.
-- Single `inviteToPortal` is unchanged; behavior and response shape are preserved.
-- Failures are isolated per invitee in `completed` mode — a single bad invite does not fail the batch.
-
-
-## Verification
-
-### Bulk invite users to a portal
-
-- `npm test -- tests/unit/portals-bulk-invite-controller.test.ts tests/unit/concurrency.test.ts tests/unit/portals-controller.test.ts`
-- `npm run build`
-- `npm run build:sdk`
-- `npm run mcp:skills:generate` (validate blocked locally: `skills-ref` Python module unavailable in this environment)
-
-
-## Follow-ups
-
-### Bulk invite users to a portal
-
-- Background mode is fire-and-forget within the request pod; if durable retry/observability is later required, move bulk processing to a worker/queue.
+- None

package/release-notes/2.3.12.md

@@ -1,53 +0,0 @@
-# Release Notes 2.3.12
-
-- Current ref: `HEAD`
-- Previous tag: `v2.3.12`
-- Generated at: 2026-06-29T08:59:27.274Z
-
-## Included Drafts
-
-- `docs/release-notes/2026-06-16-bulk-invite-to-portal.md` - Bulk invite users to a portal
-
-## Summary
-
-### Bulk invite users to a portal
-
-Gate exposes `POST /:orgId/portals/:portalId/invite/bulk` (`bulkInviteToPortal`) to invite many users to a single portal in one request, replacing N sequential `inviteToPortal` calls. Invites run with bounded concurrency (default 5, max 5); the rest are queued. Portal discovery (`listPortals`/`getPortal`) runs once for the whole batch. An optional `background` mode returns immediately without blocking the caller.
-
-
-## API / SDK Changes
-
-### Bulk invite users to a portal
-
-- Added `bulkInviteToPortal` operation and `PortalsApi.bulkInviteToPortal` SDK client method.
-- Request: `invitations[]` (each item matches `inviteToPortal`: `email` required; optional `fullName`, `orgRole`, `workspaceRole`, `isFullAccess`), optional `concurrency` (1..5, default 5), optional `background` (default false).
-- Response: `total`, `status` (`completed` | `processing`). For `completed`: `succeeded`, `failed`, `results[]` (`{ email, status, magicLink?, url?, userId?, error? }`). For `processing`: `accepted`.
-- Per-invitation `orgRole`/`isFullAccess` semantics are identical to `inviteToPortal` (shared `invitePortalUser` helper).
-- Permission: `portals.manage` with org-scoped authz (same as `inviteToPortal`).
-- MCP: `bulkInviteToPortal` is MCP-visible under the `portals` prompt group; the prompt now documents batching, concurrency, background mode, and the client access-clarification rule.
-
-
-## Consumer Impact
-
-### Bulk invite users to a portal
-
-- App agents inviting several clients can issue one call instead of N blocking sequential requests.
-- Single `inviteToPortal` is unchanged; behavior and response shape are preserved.
-- Failures are isolated per invitee in `completed` mode — a single bad invite does not fail the batch.
-
-
-## Verification
-
-### Bulk invite users to a portal
-
-- `npm test -- tests/unit/portals-bulk-invite-controller.test.ts tests/unit/concurrency.test.ts tests/unit/portals-controller.test.ts`
-- `npm run build`
-- `npm run build:sdk`
-- `npm run mcp:skills:generate` (validate blocked locally: `skills-ref` Python module unavailable in this environment)
-
-
-## Follow-ups
-
-### Bulk invite users to a portal
-
-- Background mode is fire-and-forget within the request pod; if durable retry/observability is later required, move bulk processing to a worker/queue.