@zyphr-dev/node-sdk 0.1.58 → 0.1.59

package/dist/index.d.cts

@@ -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.  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.
@@ -28150,7 +28150,7 @@ interface DevicesApiInterface {
      */
     registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<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 | 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.  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
      */
     registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<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 | InitOverrideFunction): Promise<DeviceResponse>;

package/dist/index.d.ts

@@ -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.  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.
@@ -28150,7 +28150,7 @@ interface DevicesApiInterface {
      */
     registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<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 | 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.  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
      */
     registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | InitOverrideFunction): Promise<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 | InitOverrideFunction): Promise<DeviceResponse>;

package/dist/index.js

@@ -21372,7 +21372,7 @@ var DevicesApi = class extends BaseAPI {
     return await response.value();
   }
   /**
-   * 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, initOverrides) {
@@ -21385,6 +21385,14 @@ var DevicesApi = class extends BaseAPI {
     const queryParameters = {};
     const headerParameters = {};
     headerParameters["Content-Type"] = "application/json";
+    if (this.configuration && this.configuration.apiKey) {
+      {
+        const apiKeyValue = await this.configuration.apiKey("X-Application-Secret");
+        if (apiKeyValue) {
+          headerParameters["X-Application-Secret"] = apiKeyValue;
+        }
+      }
+    }
     if (this.configuration && this.configuration.apiKey) {
       {
         const apiKeyValue = await this.configuration.apiKey("X-API-Key");
@@ -21393,6 +21401,14 @@ var DevicesApi = class extends BaseAPI {
         }
       }
     }
+    if (this.configuration && this.configuration.apiKey) {
+      {
+        const apiKeyValue = await this.configuration.apiKey("X-Application-Key");
+        if (apiKeyValue) {
+          headerParameters["X-Application-Key"] = apiKeyValue;
+        }
+      }
+    }
     const response = await this.request({
       path: `/devices`,
       method: "POST",
@@ -21403,7 +21419,7 @@ var DevicesApi = class extends BaseAPI {
     return new JSONApiResponse(response, (jsonValue) => DeviceResponseFromJSON(jsonValue));
   }
   /**
-   * 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, initOverrides) {