@zyphr-dev/node-sdk 0.1.57 → 0.1.58

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zyphr-dev/node-sdk",
-  "version": "0.1.57",
+  "version": "0.1.58",
   "description": "Official Zyphr SDK for Node.js, React, and React Native",
   "type": "module",
   "main": "./dist/index.cjs",

package/src/src/apis/AuthEmailVerificationApi.ts

@@ -57,7 +57,7 @@ export interface AuthEmailVerificationApiSendEmailVerificationOperationRequest {
  */
 export interface AuthEmailVerificationApiInterface {
     /**
-     * Verify the user\'s email using a token you collected yourself. IMPORTANT: the emailed verification LINK verifies the address server-side **on click** and then redirects to `redirect_url`. So if you take the token off that redirect and post it here, it is already redeemed — and this endpoint treats that as an idempotent **success** (`200` with `already_verified: true`), not an error. Only a genuinely invalid / expired / unknown token returns `400`. `send` / `confirm` / `resend` are NOT a mandatory matched set — `confirm` is for flows where you collect the token directly rather than landing the hosted redirect. Recommended pattern for the redirect landing: call `confirm`, ignore its result, then read the user\'s verified state back and report that — correct whether or not the link already consumed the token.
+     * Verify the user\'s email using the token from the emailed link. Zyphr does NOT host auth pages and never redeems the token itself. The emailed link points at YOUR `redirect_url` with `?token=<raw>`; your app reads that token and posts it here. Nothing is verified until this call. This endpoint is idempotent: re-posting an already-redeemed token returns `200` with `already_verified: true` rather than an error, so a double submit or a link opened twice is safe. Only a genuinely invalid / expired / unknown token returns `400`. Note `redirect_url` is REQUIRED (snake_case) when sending the verification email — there is no hosted fallback page.
      * @summary Confirm email verification
      * @param {ConfirmEmailVerificationRequest} confirmEmailVerificationRequest 
      * @param {*} [options] Override http request option.
@@ -67,7 +67,7 @@ export interface AuthEmailVerificationApiInterface {
     confirmEmailVerificationRaw(requestParameters: AuthEmailVerificationApiConfirmEmailVerificationOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ConfirmEmailVerificationResponse>>;
 
     /**
-     * Verify the user\'s email using a token you collected yourself. IMPORTANT: the emailed verification LINK verifies the address server-side **on click** and then redirects to `redirect_url`. So if you take the token off that redirect and post it here, it is already redeemed — and this endpoint treats that as an idempotent **success** (`200` with `already_verified: true`), not an error. Only a genuinely invalid / expired / unknown token returns `400`. `send` / `confirm` / `resend` are NOT a mandatory matched set — `confirm` is for flows where you collect the token directly rather than landing the hosted redirect. Recommended pattern for the redirect landing: call `confirm`, ignore its result, then read the user\'s verified state back and report that — correct whether or not the link already consumed the token.
+     * Verify the user\'s email using the token from the emailed link. Zyphr does NOT host auth pages and never redeems the token itself. The emailed link points at YOUR `redirect_url` with `?token=<raw>`; your app reads that token and posts it here. Nothing is verified until this call. This endpoint is idempotent: re-posting an already-redeemed token returns `200` with `already_verified: true` rather than an error, so a double submit or a link opened twice is safe. Only a genuinely invalid / expired / unknown token returns `400`. Note `redirect_url` is REQUIRED (snake_case) when sending the verification email — there is no hosted fallback page.
      * Confirm email verification
      */
     confirmEmailVerification(confirmEmailVerificationRequest: ConfirmEmailVerificationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ConfirmEmailVerificationResponse>;
@@ -112,7 +112,7 @@ export interface AuthEmailVerificationApiInterface {
 export class AuthEmailVerificationApi extends runtime.BaseAPI implements AuthEmailVerificationApiInterface {
 
     /**
-     * Verify the user\'s email using a token you collected yourself. IMPORTANT: the emailed verification LINK verifies the address server-side **on click** and then redirects to `redirect_url`. So if you take the token off that redirect and post it here, it is already redeemed — and this endpoint treats that as an idempotent **success** (`200` with `already_verified: true`), not an error. Only a genuinely invalid / expired / unknown token returns `400`. `send` / `confirm` / `resend` are NOT a mandatory matched set — `confirm` is for flows where you collect the token directly rather than landing the hosted redirect. Recommended pattern for the redirect landing: call `confirm`, ignore its result, then read the user\'s verified state back and report that — correct whether or not the link already consumed the token.
+     * Verify the user\'s email using the token from the emailed link. Zyphr does NOT host auth pages and never redeems the token itself. The emailed link points at YOUR `redirect_url` with `?token=<raw>`; your app reads that token and posts it here. Nothing is verified until this call. This endpoint is idempotent: re-posting an already-redeemed token returns `200` with `already_verified: true` rather than an error, so a double submit or a link opened twice is safe. Only a genuinely invalid / expired / unknown token returns `400`. Note `redirect_url` is REQUIRED (snake_case) when sending the verification email — there is no hosted fallback page.
      * Confirm email verification
      */
     async confirmEmailVerificationRaw(requestParameters: AuthEmailVerificationApiConfirmEmailVerificationOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ConfirmEmailVerificationResponse>> {
@@ -163,7 +163,7 @@ export class AuthEmailVerificationApi extends runtime.BaseAPI implements AuthEma
     }
 
     /**
-     * Verify the user\'s email using a token you collected yourself. IMPORTANT: the emailed verification LINK verifies the address server-side **on click** and then redirects to `redirect_url`. So if you take the token off that redirect and post it here, it is already redeemed — and this endpoint treats that as an idempotent **success** (`200` with `already_verified: true`), not an error. Only a genuinely invalid / expired / unknown token returns `400`. `send` / `confirm` / `resend` are NOT a mandatory matched set — `confirm` is for flows where you collect the token directly rather than landing the hosted redirect. Recommended pattern for the redirect landing: call `confirm`, ignore its result, then read the user\'s verified state back and report that — correct whether or not the link already consumed the token.
+     * Verify the user\'s email using the token from the emailed link. Zyphr does NOT host auth pages and never redeems the token itself. The emailed link points at YOUR `redirect_url` with `?token=<raw>`; your app reads that token and posts it here. Nothing is verified until this call. This endpoint is idempotent: re-posting an already-redeemed token returns `200` with `already_verified: true` rather than an error, so a double submit or a link opened twice is safe. Only a genuinely invalid / expired / unknown token returns `400`. Note `redirect_url` is REQUIRED (snake_case) when sending the verification email — there is no hosted fallback page.
      * Confirm email verification
      */
     async confirmEmailVerification(confirmEmailVerificationRequest: ConfirmEmailVerificationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ConfirmEmailVerificationResponse> {