@delopay/sdk 0.186.0 → 0.187.0

package/dist/index.cjs

@@ -4131,9 +4131,19 @@ var Users = class {
    * Mints a session token **as** the given member, so the dashboard renders
    * exactly what they see (useful for support and role verification). The
    * caller needs the *Impersonation* permission, and the member's role must
-   * rank **strictly below** the caller's (`Profile < Merchant < Organization`);
-   * the server rejects self-impersonation, cross-merchant targets, and
-   * equal/higher roles.
+   * either rank **strictly below** the caller's
+   * (`Profile < Merchant < Organization`), or sit at the caller's own
+   * merchant-or-higher level and be **strictly narrower** than the caller's
+   * role (grant nothing the caller's role does not, and less in total). The
+   * server rejects self-impersonation and cross-merchant targets.
+   * `MinimalRoleInfo.can_impersonate` in `listUsersInLineage` answers the same rule
+   * per binding, so a UI can offer the action only where it will succeed.
+   *
+   * A role refusal is a `UR_33` error whose `data.reason` names the rule:
+   * `impersonation_target_not_narrower` (the member's role is above, equal to,
+   * or not contained in the caller's), or `act_as_token_cannot_impersonate`
+   * (the caller is itself signed in as another member — start from your own
+   * session).
    *
    * The returned token is tab-scoped by design: open it in a fresh tab (e.g.
    * `/auth/impersonate?token=…`) rather than replacing the caller's own
@@ -5309,6 +5319,20 @@ var Products = class {
       ...this.scoped(profileId, options)
     });
   }
+  /**
+   * Delete an archived product, then carry out the chosen action at each
+   * connected account it is tied to. An account not named in
+   * `provider_actions` is kept as it is. A failed provider action does not
+   * undo the delete: it is listed by {@link providerCleanups} and retried
+   * with {@link providerArchive}.
+   * `POST /products/{product_id}/delete`
+   */
+  async deleteWithProviders(productId, request, profileId, options) {
+    return this.request("POST", `/products/${encodeURIComponent(productId)}/delete`, {
+      body: request,
+      ...this.scoped(profileId, options)
+    });
+  }
   /**
    * Add a price to an existing product.
    * `POST /products/{product_id}/prices`
@@ -5550,9 +5574,12 @@ var Products = class {
   }
   /**
    * Create a product for every new item and add the new prices of every
-   * changed one, tied to the provider's ids. Nothing is edited or removed, and
-   * nothing is written to the provider. A failed item is reported with its
-   * reason and can be retried by naming it in `connector_product_ids`.
+   * changed one, tied to the provider's ids. Nothing else is edited or
+   * removed, except that `options.archived: 'archive'` archives the catalog
+   * product of every item the provider no longer offers (by default it is
+   * left as it is). Nothing is written to the provider. A failed item is
+   * reported with its reason and can be retried by naming it in
+   * `connector_product_ids`.
    * `POST /products/import/apply`
    */
   async importApply(request, profileId, options) {
@@ -5609,6 +5636,53 @@ var Products = class {
       ...this.scoped(profileId, options)
     });
   }
+  // --- provider lifecycle -----------------------------------------
+  /**
+   * The shop's connected accounts the catalog works with, and what each can
+   * do: read, create, push, and how a delete can clean up there.
+   * `GET /products/provider-accounts`
+   */
+  async providerAccounts(profileId, options) {
+    return this.request("GET", "/products/provider-accounts", {
+      ...this.scoped(profileId, options)
+    });
+  }
+  /**
+   * Provider clean-ups still to be carried out: deletes whose action at a
+   * provider failed, or was recorded and never reached.
+   * `GET /products/provider-cleanups`
+   */
+  async providerCleanups(profileId, options) {
+    return this.request("GET", "/products/provider-cleanups", {
+      ...this.scoped(profileId, options)
+    });
+  }
+  /**
+   * Create the product at a connected account it is not at yet. Without
+   * `confirmed` nothing is written and the answer holds the plan to review;
+   * send the plan's `fingerprint` back as `confirmed` to carry it out. When
+   * the plan changed since, nothing is written and the answer carries
+   * `confirmation_outdated: true` with the current plan.
+   * `POST /products/{product_id}/provider-sync/create`
+   */
+  async providerCreate(productId, request, profileId, options) {
+    return this.request("POST", `/products/${encodeURIComponent(productId)}/provider-sync/create`, {
+      body: request,
+      ...this.scoped(profileId, options)
+    });
+  }
+  /**
+   * Archive the product at one connected account, or retry a clean-up that
+   * failed after the product was deleted. Existing subscriptions there keep
+   * billing; the catalog is not changed.
+   * `POST /products/{product_id}/provider-archive`
+   */
+  async providerArchive(productId, request, profileId, options) {
+    return this.request("POST", `/products/${encodeURIComponent(productId)}/provider-archive`, {
+      body: request,
+      ...this.scoped(profileId, options)
+    });
+  }
 };
 
 // src/resources/processorCosts.ts
@@ -6541,7 +6615,10 @@ var OperationLimits = class {
    *
    * Refused for the user who requested it, and for an approver whose own
    * limit would not have covered the operation — the permission is necessary
-   * and not sufficient.
+   * and not sufficient. The requester stays refused while signed in as
+   * another team member: that is a `DE_12` error (`approval_decision_refused`)
+   * whose `data.reason` is `requester_acting_as_another_member`, and
+   * {@link reject} refuses the same way.
    *
    * Approval and execution are two facts. A request that was approved but
    * whose operation then failed comes back `approved` with `execution_error`
@@ -10304,6 +10381,27 @@ var CheckoutSession = class {
       headers: this.bearerHeaders(options?.headers)
     });
   }
+  /**
+   * Make the buyer's add-on choice while the checkout data answers
+   * `type: 'addon_choice'`.
+   *
+   * Only price ids and quantities are sent; the router prices them from the
+   * catalog and judges every selection group's bounds. The payment's lines and
+   * amount change together, once: the choice is final afterwards, the same
+   * choice sent again answers the same result, and another is refused with
+   * `IR_16` — as is a choice once anything could have been charged at the
+   * previous amount. Fetch the checkout data again afterwards for the payment
+   * methods at the final amount.
+   *
+   * `POST /payment-link/{merchantId}/{paymentId}/addons`
+   */
+  async chooseAddons(params, options) {
+    return this.client.request("POST", `${this.linkBase}/addons`, {
+      body: params,
+      ...options,
+      headers: this.bearerHeaders(options?.headers)
+    });
+  }
   /**
    * Ask whether NomuPay's COPYandPAY widget may submit a card, from the
    * form's pre-submit hook.