@zyphr-dev/node-sdk 0.1.56 → 0.1.58

package/dist/index.d.cts

@@ -25779,7 +25779,7 @@ interface AuthEmailVerificationApiSendEmailVerificationOperationRequest {
  */
 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.
@@ -25788,7 +25788,7 @@ interface AuthEmailVerificationApiInterface {
      */
     confirmEmailVerificationRaw(requestParameters: AuthEmailVerificationApiConfirmEmailVerificationOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<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 | InitOverrideFunction): Promise<ConfirmEmailVerificationResponse>;
@@ -25826,12 +25826,12 @@ interface AuthEmailVerificationApiInterface {
  */
 declare class AuthEmailVerificationApi extends 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
      */
     confirmEmailVerificationRaw(requestParameters: AuthEmailVerificationApiConfirmEmailVerificationOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<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 | InitOverrideFunction): Promise<ConfirmEmailVerificationResponse>;
@@ -28141,7 +28141,7 @@ interface DevicesApiInterface {
      */
     listDevices(userId?: string, platform?: ListDevicesPlatformEnum, limit?: number, offset?: number, initOverrides?: RequestInit | InitOverrideFunction): Promise<DeviceListResponse>;
     /**
-     * Register a device for push notifications. If the token already exists, updates it.
+     * Register a device for push notifications.  Registration is an upsert keyed on (project, token), so calling it on every app launch is safe and idempotent. Re-registering an existing token under a different `user_id` **reassigns** the device to that user — the previous association does not persist, so a push addressed to the old user will not reach this device.  `user_id` is an opaque string you choose. It is stored verbatim with no foreign key, and `POST /v1/push` matches on exactly that value. No Subscriber record is created for you.  Requires a secret API key, so call it from your backend and derive `user_id` from the authenticated session rather than the request body.
      * @summary Register a device
      * @param {RegisterDeviceRequest} registerDeviceRequest
      * @param {*} [options] Override http request option.
@@ -28150,7 +28150,7 @@ interface DevicesApiInterface {
      */
     registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<ApiResponse<DeviceResponse>>;
     /**
-     * Register a device for push notifications. If the token already exists, updates it.
+     * Register a device for push notifications.  Registration is an upsert keyed on (project, token), so calling it on every app launch is safe and idempotent. Re-registering an existing token under a different `user_id` **reassigns** the device to that user — the previous association does not persist, so a push addressed to the old user will not reach this device.  `user_id` is an opaque string you choose. It is stored verbatim with no foreign key, and `POST /v1/push` matches on exactly that value. No Subscriber record is created for you.  Requires a secret API key, so call it from your backend and derive `user_id` from the authenticated session rather than the request body.
      * Register a device
      */
     registerDevice(registerDeviceRequest: RegisterDeviceRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<DeviceResponse>;
@@ -28210,12 +28210,12 @@ declare class DevicesApi extends BaseAPI implements DevicesApiInterface {
      */
     listDevices(userId?: string, platform?: ListDevicesPlatformEnum, limit?: number, offset?: number, initOverrides?: RequestInit | InitOverrideFunction): Promise<DeviceListResponse>;
     /**
-     * Register a device for push notifications. If the token already exists, updates it.
+     * Register a device for push notifications.  Registration is an upsert keyed on (project, token), so calling it on every app launch is safe and idempotent. Re-registering an existing token under a different `user_id` **reassigns** the device to that user — the previous association does not persist, so a push addressed to the old user will not reach this device.  `user_id` is an opaque string you choose. It is stored verbatim with no foreign key, and `POST /v1/push` matches on exactly that value. No Subscriber record is created for you.  Requires a secret API key, so call it from your backend and derive `user_id` from the authenticated session rather than the request body.
      * Register a device
      */
     registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<ApiResponse<DeviceResponse>>;
     /**
-     * Register a device for push notifications. If the token already exists, updates it.
+     * Register a device for push notifications.  Registration is an upsert keyed on (project, token), so calling it on every app launch is safe and idempotent. Re-registering an existing token under a different `user_id` **reassigns** the device to that user — the previous association does not persist, so a push addressed to the old user will not reach this device.  `user_id` is an opaque string you choose. It is stored verbatim with no foreign key, and `POST /v1/push` matches on exactly that value. No Subscriber record is created for you.  Requires a secret API key, so call it from your backend and derive `user_id` from the authenticated session rather than the request body.
      * Register a device
      */
     registerDevice(registerDeviceRequest: RegisterDeviceRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<DeviceResponse>;
@@ -33647,8 +33647,6 @@ declare class ZyphrClient {
         readonly profile: AuthUserProfileApi;
         readonly webauthn: AuthWebAuthnApi;
     };
-    /** Device registration for push (takes an OS-acquired token). */
-    readonly devices: DevicesApi;
     /**
      * Utility endpoints that are publishable-key-safe: the application's password
      * policy (`getPasswordRequirements`) and a pre-submit password strength check

package/dist/index.d.ts

@@ -25779,7 +25779,7 @@ interface AuthEmailVerificationApiSendEmailVerificationOperationRequest {
  */
 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.
@@ -25788,7 +25788,7 @@ interface AuthEmailVerificationApiInterface {
      */
     confirmEmailVerificationRaw(requestParameters: AuthEmailVerificationApiConfirmEmailVerificationOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<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 | InitOverrideFunction): Promise<ConfirmEmailVerificationResponse>;
@@ -25826,12 +25826,12 @@ interface AuthEmailVerificationApiInterface {
  */
 declare class AuthEmailVerificationApi extends 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
      */
     confirmEmailVerificationRaw(requestParameters: AuthEmailVerificationApiConfirmEmailVerificationOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<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 | InitOverrideFunction): Promise<ConfirmEmailVerificationResponse>;
@@ -28141,7 +28141,7 @@ interface DevicesApiInterface {
      */
     listDevices(userId?: string, platform?: ListDevicesPlatformEnum, limit?: number, offset?: number, initOverrides?: RequestInit | InitOverrideFunction): Promise<DeviceListResponse>;
     /**
-     * Register a device for push notifications. If the token already exists, updates it.
+     * Register a device for push notifications.  Registration is an upsert keyed on (project, token), so calling it on every app launch is safe and idempotent. Re-registering an existing token under a different `user_id` **reassigns** the device to that user — the previous association does not persist, so a push addressed to the old user will not reach this device.  `user_id` is an opaque string you choose. It is stored verbatim with no foreign key, and `POST /v1/push` matches on exactly that value. No Subscriber record is created for you.  Requires a secret API key, so call it from your backend and derive `user_id` from the authenticated session rather than the request body.
      * @summary Register a device
      * @param {RegisterDeviceRequest} registerDeviceRequest
      * @param {*} [options] Override http request option.
@@ -28150,7 +28150,7 @@ interface DevicesApiInterface {
      */
     registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<ApiResponse<DeviceResponse>>;
     /**
-     * Register a device for push notifications. If the token already exists, updates it.
+     * Register a device for push notifications.  Registration is an upsert keyed on (project, token), so calling it on every app launch is safe and idempotent. Re-registering an existing token under a different `user_id` **reassigns** the device to that user — the previous association does not persist, so a push addressed to the old user will not reach this device.  `user_id` is an opaque string you choose. It is stored verbatim with no foreign key, and `POST /v1/push` matches on exactly that value. No Subscriber record is created for you.  Requires a secret API key, so call it from your backend and derive `user_id` from the authenticated session rather than the request body.
      * Register a device
      */
     registerDevice(registerDeviceRequest: RegisterDeviceRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<DeviceResponse>;
@@ -28210,12 +28210,12 @@ declare class DevicesApi extends BaseAPI implements DevicesApiInterface {
      */
     listDevices(userId?: string, platform?: ListDevicesPlatformEnum, limit?: number, offset?: number, initOverrides?: RequestInit | InitOverrideFunction): Promise<DeviceListResponse>;
     /**
-     * Register a device for push notifications. If the token already exists, updates it.
+     * Register a device for push notifications.  Registration is an upsert keyed on (project, token), so calling it on every app launch is safe and idempotent. Re-registering an existing token under a different `user_id` **reassigns** the device to that user — the previous association does not persist, so a push addressed to the old user will not reach this device.  `user_id` is an opaque string you choose. It is stored verbatim with no foreign key, and `POST /v1/push` matches on exactly that value. No Subscriber record is created for you.  Requires a secret API key, so call it from your backend and derive `user_id` from the authenticated session rather than the request body.
      * Register a device
      */
     registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<ApiResponse<DeviceResponse>>;
     /**
-     * Register a device for push notifications. If the token already exists, updates it.
+     * Register a device for push notifications.  Registration is an upsert keyed on (project, token), so calling it on every app launch is safe and idempotent. Re-registering an existing token under a different `user_id` **reassigns** the device to that user — the previous association does not persist, so a push addressed to the old user will not reach this device.  `user_id` is an opaque string you choose. It is stored verbatim with no foreign key, and `POST /v1/push` matches on exactly that value. No Subscriber record is created for you.  Requires a secret API key, so call it from your backend and derive `user_id` from the authenticated session rather than the request body.
      * Register a device
      */
     registerDevice(registerDeviceRequest: RegisterDeviceRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<DeviceResponse>;
@@ -33647,8 +33647,6 @@ declare class ZyphrClient {
         readonly profile: AuthUserProfileApi;
         readonly webauthn: AuthWebAuthnApi;
     };
-    /** Device registration for push (takes an OS-acquired token). */
-    readonly devices: DevicesApi;
     /**
      * Utility endpoints that are publishable-key-safe: the application's password
      * policy (`getPasswordRequirements`) and a pre-submit password strength check