@delopay/sdk 0.3.2 → 0.3.3

package/dist/index.d.cts

@@ -2985,15 +2985,20 @@ declare class Users {
     rotatePassword(params: ResetPasswordRequest): Promise<UserResponse>;
     forgotPassword(params: ForgotPasswordRequest): Promise<Record<string, unknown>>;
     /**
-     * Reset a user's password using the single-purpose JWT delivered by the
-     * forgot-password email.
-     *
-     * The backend validates the token **twice**: first by the
-     * `SinglePurposeJWTAuth` middleware (reads `Authorization: Bearer …`),
-     * then by the handler itself (decodes `body.token` as an `EmailToken` and
-     * looks up the user by the embedded email — see
-     * `crates/router/src/core/user.rs:687`). The same JWT satisfies both, so
-     * the SDK sends it in both places. Callers still pass `{ password, token }`.
+     * Reset a user's password using the email link token.
+     *
+     * The email link delivers an `EmailToken`, but `/user/reset_password` is
+     * gated by `SinglePurposeJWTAuth` which expects a different JWT type
+     * (`SinglePurposeToken`). The SDK hides this two-step dance:
+     *
+     * 1. Exchange the EmailToken for a SinglePurposeToken at `/user/from_email`
+     *    (`crates/router/src/core/user.rs:2773`, no auth required).
+     * 2. Call `/user/reset_password` with the SinglePurposeToken as
+     *    `Authorization: Bearer` and the original EmailToken in the body —
+     *    the handler decodes body.token as an EmailToken to look up the user
+     *    (`crates/router/src/core/user.rs:687`).
+     *
+     * Callers just pass `{ password, token }` (the token from the URL).
      */
     resetPassword(params: ResetPasswordRequest): Promise<Record<string, unknown>>;
     verifyEmail(params: Record<string, unknown>): Promise<AuthResponse>;

package/dist/index.d.ts

@@ -2985,15 +2985,20 @@ declare class Users {
     rotatePassword(params: ResetPasswordRequest): Promise<UserResponse>;
     forgotPassword(params: ForgotPasswordRequest): Promise<Record<string, unknown>>;
     /**
-     * Reset a user's password using the single-purpose JWT delivered by the
-     * forgot-password email.
-     *
-     * The backend validates the token **twice**: first by the
-     * `SinglePurposeJWTAuth` middleware (reads `Authorization: Bearer …`),
-     * then by the handler itself (decodes `body.token` as an `EmailToken` and
-     * looks up the user by the embedded email — see
-     * `crates/router/src/core/user.rs:687`). The same JWT satisfies both, so
-     * the SDK sends it in both places. Callers still pass `{ password, token }`.
+     * Reset a user's password using the email link token.
+     *
+     * The email link delivers an `EmailToken`, but `/user/reset_password` is
+     * gated by `SinglePurposeJWTAuth` which expects a different JWT type
+     * (`SinglePurposeToken`). The SDK hides this two-step dance:
+     *
+     * 1. Exchange the EmailToken for a SinglePurposeToken at `/user/from_email`
+     *    (`crates/router/src/core/user.rs:2773`, no auth required).
+     * 2. Call `/user/reset_password` with the SinglePurposeToken as
+     *    `Authorization: Bearer` and the original EmailToken in the body —
+     *    the handler decodes body.token as an EmailToken to look up the user
+     *    (`crates/router/src/core/user.rs:687`).
+     *
+     * Callers just pass `{ password, token }` (the token from the URL).
      */
     resetPassword(params: ResetPasswordRequest): Promise<Record<string, unknown>>;
     verifyEmail(params: Record<string, unknown>): Promise<AuthResponse>;

package/dist/index.js

@@ -2030,20 +2030,30 @@ var Users = class {
     return this.request("POST", "/user/forgot_password", { body: params });
   }
   /**
-   * Reset a user's password using the single-purpose JWT delivered by the
-   * forgot-password email.
+   * Reset a user's password using the email link token.
    *
-   * The backend validates the token **twice**: first by the
-   * `SinglePurposeJWTAuth` middleware (reads `Authorization: Bearer …`),
-   * then by the handler itself (decodes `body.token` as an `EmailToken` and
-   * looks up the user by the embedded email — see
-   * `crates/router/src/core/user.rs:687`). The same JWT satisfies both, so
-   * the SDK sends it in both places. Callers still pass `{ password, token }`.
+   * The email link delivers an `EmailToken`, but `/user/reset_password` is
+   * gated by `SinglePurposeJWTAuth` which expects a different JWT type
+   * (`SinglePurposeToken`). The SDK hides this two-step dance:
+   *
+   * 1. Exchange the EmailToken for a SinglePurposeToken at `/user/from_email`
+   *    (`crates/router/src/core/user.rs:2773`, no auth required).
+   * 2. Call `/user/reset_password` with the SinglePurposeToken as
+   *    `Authorization: Bearer` and the original EmailToken in the body —
+   *    the handler decodes body.token as an EmailToken to look up the user
+   *    (`crates/router/src/core/user.rs:687`).
+   *
+   * Callers just pass `{ password, token }` (the token from the URL).
    */
   async resetPassword(params) {
+    const exchange = await this.request(
+      "POST",
+      "/user/from_email",
+      { body: { token: params.token } }
+    );
     return this.request("POST", "/user/reset_password", {
-      body: params,
-      headers: { Authorization: `Bearer ${params.token}` }
+      body: { token: params.token, password: params.password },
+      headers: { Authorization: `Bearer ${exchange.token}` }
     });
   }
   async verifyEmail(params) {