@delopay/sdk 0.99.0 → 0.100.2

package/dist/{chunk-MUP6NKMP.js → chunk-6ULG3SLG.js}

@@ -105,8 +105,7 @@ var ApiKeys = class {
   // JWT-authenticated routes under `/account/{merchantId}/profile/api-keys`.
   // The caller's shop (business profile) comes from the JWT, never from the
   // request, so a shop-scoped user can only mint/list/manage keys pinned to
-  // their own shop. Requires a backend with profile-scoped API key support
-  // (DeloPay-net/delopay-backend#344).
+  // their own shop. Requires a backend with profile-scoped API key support.
   /**
    * Create a new API key pinned to the caller's shop (business profile).
    * `POST /account/{merchantId}/profile/api-keys`
@@ -3134,6 +3133,45 @@ var Users = class {
   async deleteRole(roleId) {
     return this.request("DELETE", `/user/role/${encodeURIComponent(roleId)}`);
   }
+  /**
+   * Read which individual connector accounts a role may see.
+   *
+   * `GET /user/role/{roleId}/connectors`
+   *
+   * **Check `restricted` before reading `connectors`.** An empty list is
+   * ambiguous by itself, so the backend states which case it is: `false` means
+   * the role holds no grant and sees whatever its entity and profile scope
+   * already allowed. Rendering an empty `connectors` array as "this role sees
+   * nothing" inverts the meaning.
+   *
+   * Requires the permission that *edits a role*, not a connector permission.
+   */
+  async getRoleConnectors(roleId) {
+    return this.request("GET", `/user/role/${encodeURIComponent(roleId)}/connectors`);
+  }
+  /**
+   * Replace the set of connector accounts a role may see.
+   *
+   * `PUT /user/role/{roleId}/connectors`
+   *
+   * The call **replaces** the whole set rather than adding to it, so send the
+   * complete list every time. An empty `merchant_connector_ids` clears the
+   * grant and returns the role to unrestricted.
+   *
+   * The backend refuses an id that is not a connector account of the caller's
+   * own merchant, an `Organization`-scoped role (a connector account belongs to
+   * exactly one merchant, so an org-spanning role cannot hold one coherently),
+   * and any predefined role (one static entry shared by every tenant).
+   *
+   * Editing a grant invalidates the role cache and blacklists tokens minted
+   * before the edit, so **users holding this role must sign in again**. Worth
+   * saying in the UI before the save, not after.
+   */
+  async updateRoleConnectors(roleId, params) {
+    return this.request("PUT", `/user/role/${encodeURIComponent(roleId)}/connectors`, {
+      body: params
+    });
+  }
 };
 
 // src/resources/verification.ts
@@ -5572,7 +5610,7 @@ var CheckoutSession = class {
    * own types and runtime gates — hence the loose return type.
    *
    * `theme` is the route's one declared query parameter (a named checkout
-   * variant, backend#793). `locale` travels as `Accept-Language` — the only
+   * variant). `locale` travels as `Accept-Language` — the only
    * channel the backend's locale resolution reads; a `?locale=` query is
    * silently ignored by this route.
    *
@@ -5727,10 +5765,17 @@ var CheckoutSession = class {
   /**
    * A short-lived VGS Collect session for browser-side card capture.
    *
-   * A 404 — or a 400 carrying the "shop has no vault" code — means the shop
-   * has no vault configured; other errors must NOT be treated that way (a
-   * refused vault falling back to an unprotected card pane is exactly the
-   * bug this endpoint's error contract exists to prevent).
+   * **Exactly one refusal means "this shop has no vault": a 400 carrying
+   * `IR_19`.** Every other refusal means a vault exists and could not be used,
+   * and answering it by falling back to the processor's own card pane sends an
+   * unprotected card number to the very processor the shop pays to hide it
+   * from — the bug this endpoint's error contract exists to prevent.
+   *
+   * A **404 is not benign.** The router answers it when the shop's vault
+   * account cannot be found — the state a shop is left in when its vault
+   * connector is deleted while the profile keeps naming the id: it still
+   * reports the vault as enabled and still expects its cards cloaked. The same
+   * status also covers a payment that does not exist.
    *
    * `GET /payment-link/{merchantId}/{paymentId}/vault/collect-session`
    */
@@ -6129,4 +6174,4 @@ export {
   focusedCheckoutUrl,
   CHECKOUT_EVENT_KINDS
 };
-//# sourceMappingURL=chunk-MUP6NKMP.js.map
+//# sourceMappingURL=chunk-6ULG3SLG.js.map