@zyphr-dev/node-sdk 0.1.57 → 0.1.59

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zyphr-dev/node-sdk",
-  "version": "0.1.57",
+  "version": "0.1.59",
   "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> {

package/src/src/apis/DevicesApi.ts

@@ -153,7 +153,7 @@ export interface DevicesApiInterface {
     listDevices(userId?: string, platform?: ListDevicesPlatformEnum, limit?: number, offset?: number, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<DeviceListResponse>;
 
     /**
-     * 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 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.  Call this from your backend and derive `user_id` from the authenticated session rather than the request body.  **Two credentials are accepted, and the choice matters for push routing:**  - **Application credentials** — `X-Application-Key` + `X-Application-Secret`   (`za_*`). The device is bound to that application, and pushes to it   resolve *that application\'s* push provider credentials. Use this when a   single project contains more than one app: APNs credentials are bound to   a bundle id, so a device registered under the wrong application has its   pushes rejected by Apple. The application is taken from the credential   and can never be set from the request body.    Using an **environment-scoped** key (`za_test_pub_*` / `za_live_pub_*`)   also binds the device to that environment, which is what lets APNs   sandbox and production credentials be configured separately. A legacy   application-level key (`za_pub_*`) binds the application only, and such   devices will not match an environment-scoped push config.  - **Project secret API key** (`zy_*`) — the device is not bound to any   application and resolves the project-level push provider config. This is   the historical behaviour and remains supported. 
      * @summary Register a device
      * @param {RegisterDeviceRequest} registerDeviceRequest 
      * @param {*} [options] Override http request option.
@@ -163,7 +163,7 @@ export interface DevicesApiInterface {
     registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<DeviceResponse>>;
 
     /**
-     * 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 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.  Call this from your backend and derive `user_id` from the authenticated session rather than the request body.  **Two credentials are accepted, and the choice matters for push routing:**  - **Application credentials** — `X-Application-Key` + `X-Application-Secret`   (`za_*`). The device is bound to that application, and pushes to it   resolve *that application\'s* push provider credentials. Use this when a   single project contains more than one app: APNs credentials are bound to   a bundle id, so a device registered under the wrong application has its   pushes rejected by Apple. The application is taken from the credential   and can never be set from the request body.    Using an **environment-scoped** key (`za_test_pub_*` / `za_live_pub_*`)   also binds the device to that environment, which is what lets APNs   sandbox and production credentials be configured separately. A legacy   application-level key (`za_pub_*`) binds the application only, and such   devices will not match an environment-scoped push config.  - **Project secret API key** (`zy_*`) — the device is not bound to any   application and resolves the project-level push provider config. This is   the historical behaviour and remains supported. 
      * Register a device
      */
     registerDevice(registerDeviceRequest: RegisterDeviceRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<DeviceResponse>;
@@ -408,7 +408,7 @@ export class DevicesApi extends runtime.BaseAPI implements DevicesApiInterface {
     }
 
     /**
-     * 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 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.  Call this from your backend and derive `user_id` from the authenticated session rather than the request body.  **Two credentials are accepted, and the choice matters for push routing:**  - **Application credentials** — `X-Application-Key` + `X-Application-Secret`   (`za_*`). The device is bound to that application, and pushes to it   resolve *that application\'s* push provider credentials. Use this when a   single project contains more than one app: APNs credentials are bound to   a bundle id, so a device registered under the wrong application has its   pushes rejected by Apple. The application is taken from the credential   and can never be set from the request body.    Using an **environment-scoped** key (`za_test_pub_*` / `za_live_pub_*`)   also binds the device to that environment, which is what lets APNs   sandbox and production credentials be configured separately. A legacy   application-level key (`za_pub_*`) binds the application only, and such   devices will not match an environment-scoped push config.  - **Project secret API key** (`zy_*`) — the device is not bound to any   application and resolves the project-level push provider config. This is   the historical behaviour and remains supported. 
      * Register a device
      */
     async registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<DeviceResponse>> {
@@ -425,6 +425,17 @@ export class DevicesApi extends runtime.BaseAPI implements DevicesApiInterface {
 
         headerParameters['Content-Type'] = 'application/json';
 
+        if (this.configuration && this.configuration.apiKey) {
+            // An unresolved credential must produce NO header, not an empty one (sc-8162).
+            {
+                const apiKeyValue = await this.configuration.apiKey("X-Application-Secret"); // ApplicationSecret authentication
+
+                if (apiKeyValue) {
+                    headerParameters["X-Application-Secret"] = apiKeyValue;
+                }
+            }
+        }
+
         if (this.configuration && this.configuration.apiKey) {
             // An unresolved credential must produce NO header, not an empty one (sc-8162).
             {
@@ -436,6 +447,17 @@ export class DevicesApi extends runtime.BaseAPI implements DevicesApiInterface {
             }
         }
 
+        if (this.configuration && this.configuration.apiKey) {
+            // An unresolved credential must produce NO header, not an empty one (sc-8162).
+            {
+                const apiKeyValue = await this.configuration.apiKey("X-Application-Key"); // ApplicationPublicKey authentication
+
+                if (apiKeyValue) {
+                    headerParameters["X-Application-Key"] = apiKeyValue;
+                }
+            }
+        }
+
         const response = await this.request({
             path: `/devices`,
             method: 'POST',
@@ -448,7 +470,7 @@ export class DevicesApi extends runtime.BaseAPI implements DevicesApiInterface {
     }
 
     /**
-     * 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 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.  Call this from your backend and derive `user_id` from the authenticated session rather than the request body.  **Two credentials are accepted, and the choice matters for push routing:**  - **Application credentials** — `X-Application-Key` + `X-Application-Secret`   (`za_*`). The device is bound to that application, and pushes to it   resolve *that application\'s* push provider credentials. Use this when a   single project contains more than one app: APNs credentials are bound to   a bundle id, so a device registered under the wrong application has its   pushes rejected by Apple. The application is taken from the credential   and can never be set from the request body.    Using an **environment-scoped** key (`za_test_pub_*` / `za_live_pub_*`)   also binds the device to that environment, which is what lets APNs   sandbox and production credentials be configured separately. A legacy   application-level key (`za_pub_*`) binds the application only, and such   devices will not match an environment-scoped push config.  - **Project secret API key** (`zy_*`) — the device is not bound to any   application and resolves the project-level push provider config. This is   the historical behaviour and remains supported. 
      * Register a device
      */
     async registerDevice(registerDeviceRequest: RegisterDeviceRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<DeviceResponse> {