@zyphr-dev/node-sdk 0.1.58 → 0.1.59

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@zyphr-dev/node-sdk",
3
- "version": "0.1.58",
3
+ "version": "0.1.59",
4
4
  "description": "Official Zyphr SDK for Node.js, React, and React Native",
5
5
  "type": "module",
6
6
  "main": "./dist/index.cjs",
@@ -153,7 +153,7 @@ export interface DevicesApiInterface {
153
153
  listDevices(userId?: string, platform?: ListDevicesPlatformEnum, limit?: number, offset?: number, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<DeviceListResponse>;
154
154
 
155
155
  /**
156
- * 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.
156
+ * 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.
157
157
  * @summary Register a device
158
158
  * @param {RegisterDeviceRequest} registerDeviceRequest
159
159
  * @param {*} [options] Override http request option.
@@ -163,7 +163,7 @@ export interface DevicesApiInterface {
163
163
  registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<DeviceResponse>>;
164
164
 
165
165
  /**
166
- * 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.
166
+ * 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.
167
167
  * Register a device
168
168
  */
169
169
  registerDevice(registerDeviceRequest: RegisterDeviceRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<DeviceResponse>;
@@ -408,7 +408,7 @@ export class DevicesApi extends runtime.BaseAPI implements DevicesApiInterface {
408
408
  }
409
409
 
410
410
  /**
411
- * 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.
411
+ * 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.
412
412
  * Register a device
413
413
  */
414
414
  async registerDeviceRaw(requestParameters: DevicesApiRegisterDeviceOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<DeviceResponse>> {
@@ -425,6 +425,17 @@ export class DevicesApi extends runtime.BaseAPI implements DevicesApiInterface {
425
425
 
426
426
  headerParameters['Content-Type'] = 'application/json';
427
427
 
428
+ if (this.configuration && this.configuration.apiKey) {
429
+ // An unresolved credential must produce NO header, not an empty one (sc-8162).
430
+ {
431
+ const apiKeyValue = await this.configuration.apiKey("X-Application-Secret"); // ApplicationSecret authentication
432
+
433
+ if (apiKeyValue) {
434
+ headerParameters["X-Application-Secret"] = apiKeyValue;
435
+ }
436
+ }
437
+ }
438
+
428
439
  if (this.configuration && this.configuration.apiKey) {
429
440
  // An unresolved credential must produce NO header, not an empty one (sc-8162).
430
441
  {
@@ -436,6 +447,17 @@ export class DevicesApi extends runtime.BaseAPI implements DevicesApiInterface {
436
447
  }
437
448
  }
438
449
 
450
+ if (this.configuration && this.configuration.apiKey) {
451
+ // An unresolved credential must produce NO header, not an empty one (sc-8162).
452
+ {
453
+ const apiKeyValue = await this.configuration.apiKey("X-Application-Key"); // ApplicationPublicKey authentication
454
+
455
+ if (apiKeyValue) {
456
+ headerParameters["X-Application-Key"] = apiKeyValue;
457
+ }
458
+ }
459
+ }
460
+
439
461
  const response = await this.request({
440
462
  path: `/devices`,
441
463
  method: 'POST',
@@ -448,7 +470,7 @@ export class DevicesApi extends runtime.BaseAPI implements DevicesApiInterface {
448
470
  }
449
471
 
450
472
  /**
451
- * 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.
473
+ * 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.
452
474
  * Register a device
453
475
  */
454
476
  async registerDevice(registerDeviceRequest: RegisterDeviceRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<DeviceResponse> {