@veltdev/sdk 5.0.2-beta.34 → 5.0.2-beta.36

package/app/models/data/notification.model.d.ts

@@ -274,8 +274,6 @@ export interface CrossOrganizationConfig {
     organizationIds?: string[];
     /** Organization IDs to exclude. The current organization is always excluded. */
     excludeOrganizationIds?: string[];
-    /** Upper bound on the number of organizations fetched. Defaults to 20. */
-    maxOrganizations?: number;
     /** Feeds the merge applies to. Only `'forYou'` is supported; `'all'` is ignored with a warning. */
     feeds?: ('forYou' | 'all')[];
 }

package/app/models/data/user.data.model.d.ts

@@ -1,4 +1,5 @@
 import { SetDocumentsContext } from "./document.data.model";
+import { ResolverEndpointConfig, ResolverResponse } from "./resolver.data.model";
 import { UserContact } from "./user-contact.data.model";
 import { UserPermissionAccessRole } from "./user-resolver.data.model";
 export declare class User {
@@ -145,6 +146,51 @@ export interface VeltPermissionProvider {
     isContextEnabled?: boolean;
     revokeAccessOn?: RevokeAccessOn[];
     forceRefresh?: boolean;
+    /**
+     * LOCAL-DEV ONLY. When `true`, the SDK resolves permissions in the browser
+     * (via {@link endpointConfig} or {@link resolvePermissions}) and relays the
+     * results to the backend, instead of relying on the server-to-server
+     * Real-Time Permission Provider. This lets a `localhost` permission endpoint
+     * be reached without an ngrok/Cloudflare tunnel during development.
+     *
+     * This flag is an ergonomic switch only — it is NOT a security boundary.
+     * The backend independently gates browser-resolved results to dev/test API
+     * keys; production keys always ignore them and fall back to the server-side
+     * provider. MUST NOT be relied on in production.
+     */
+    dev?: boolean;
+    /**
+     * URL-based client-side resolver. When set (and {@link dev} is `true`), the
+     * browser POSTs `{ data: { requests } }` to `url` — byte-for-byte identical
+     * to what the server-side permission provider sends — and expects the same
+     * `{ data: PermissionResult[], success, statusCode }` response. Takes
+     * precedence over {@link resolvePermissions} when both are provided.
+     */
+    endpointConfig?: ResolverEndpointConfig;
+    /**
+     * Callback-based client-side resolver. When set (and {@link dev} is `true`,
+     * and no {@link endpointConfig} URL is provided), it is invoked with the
+     * same `{ data: { requests } }` envelope and may return either a bare
+     * `PermissionResult[]` or a `ResolverResponse<PermissionResult[]>`.
+     */
+    resolvePermissions?: (request: PermissionResolverRequest) => Promise<PermissionResult[] | ResolverResponse<PermissionResult[]>>;
+    /**
+     * Optional per-call timeout (ms) for the client-side resolver. When the
+     * resolver does not settle within this window the check fails closed (deny).
+     */
+    resolveTimeout?: number;
+}
+/**
+ * The request envelope handed to a client-side permission resolver
+ * ({@link VeltPermissionProvider.endpointConfig} URL body or
+ * {@link VeltPermissionProvider.resolvePermissions} callback argument). The
+ * shape mirrors the server-side permission provider request byte-for-byte so a
+ * customer's existing handler works unchanged.
+ */
+export interface PermissionResolverRequest {
+    data: {
+        requests: PermissionQuery[];
+    };
 }
 export declare enum PermissionResourceType {
     FOLDER = "folder",

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@veltdev/sdk",
-    "version": "5.0.2-beta.34",
+    "version": "5.0.2-beta.36",
     "description": "Velt is an SDK to add collaborative features to your product within minutes. Example: Comments like Figma, Frame.io, Google docs or sheets, Recording like Loom, Huddles like Slack and much more.",
     "homepage": "https://velt.dev",
     "keywords": [