zyphr 0.1.57 → 0.1.59

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 5df74a41bd87130c14d2f741651f1617baade8b9ebe23f90d7edc1b112c15bc0
-  data.tar.gz: 72b9840799c7b7e72e16db2bcb96f982e5f7b9a2d4f296195d1303be7549d1fe
+  metadata.gz: 68a6a8c4ca53f0d9c241056229349324604e5041f8123f33c293e47c0ededfab
+  data.tar.gz: 4292defa42f1d859b8b3cd86a8e763313be7259c2fabbc80c995165494931c0b
 SHA512:
-  metadata.gz: 7e558a85a1ffcc94bc8e692c4d7338d89632e878daf74229f7689d3b3c2236ae0500e8d375f1ee4d039836f0bd66e33ece72db481e9fb3416916d9d039eabeef
-  data.tar.gz: dc84b266eaa34edd83b5000997e8867681378d12564c1b158a492aea6c0adcabaf1d2d28e7b7c5cdc554d5d35bf4905d8f3986745613c10cc4f0030c0530dede
+  metadata.gz: c4205020ca0940fde2cfb3cf1f4d6b0b6705273fe93ee111fdd3ac4040773483dacf0d3d26335aea4a3b999dad58ac52a818f729799a7a02f30e3ed4a5de06df
+  data.tar.gz: 48d3cc59856b33e78258731f226414caabd39e531059c838853382c0df13ae78001434d3ab3b777f304984744249599e364d9979a6f34bfaf3ca3a39833eedab

data/docs/AuthEmailVerificationApi.md

@@ -15,7 +15,7 @@ All URIs are relative to *https://api.zyphr.dev/v1*
 
 Confirm email verification
 
-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.
 
 ### Examples
 

data/docs/DevicesApi.md

@@ -378,7 +378,7 @@ end
 
 Register a device
 
-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. 
 
 ### Examples
 
@@ -387,10 +387,20 @@ require 'time'
 require 'zyphr'
 # setup authorization
 Zyphr.configure do |config|
+  # Configure API key authorization: ApplicationSecret
+  config.api_key['X-Application-Secret'] = 'YOUR API KEY'
+  # Uncomment the following line to set a prefix for the API key, e.g. 'Bearer' (defaults to nil)
+  # config.api_key_prefix['X-Application-Secret'] = 'Bearer'
+
   # Configure API key authorization: ApiKeyAuth
   config.api_key['X-API-Key'] = 'YOUR API KEY'
   # Uncomment the following line to set a prefix for the API key, e.g. 'Bearer' (defaults to nil)
   # config.api_key_prefix['X-API-Key'] = 'Bearer'
+
+  # Configure API key authorization: ApplicationPublicKey
+  config.api_key['X-Application-Key'] = 'YOUR API KEY'
+  # Uncomment the following line to set a prefix for the API key, e.g. 'Bearer' (defaults to nil)
+  # config.api_key_prefix['X-Application-Key'] = 'Bearer'
 end
 
 api_instance = Zyphr::DevicesApi.new
@@ -435,7 +445,7 @@ end
 
 ### Authorization
 
-[ApiKeyAuth](../README.md#ApiKeyAuth)
+[ApplicationSecret](../README.md#ApplicationSecret), [ApiKeyAuth](../README.md#ApiKeyAuth), [ApplicationPublicKey](../README.md#ApplicationPublicKey)
 
 ### HTTP request headers
 

data/lib/zyphr/api/auth_email_verification_api.rb

@@ -20,7 +20,7 @@ module Zyphr
       @api_client = api_client
     end
     # Confirm email verification
-    # 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.
     # @param confirm_email_verification_request [ConfirmEmailVerificationRequest] 
     # @param [Hash] opts the optional parameters
     # @return [ConfirmEmailVerificationResponse]
@@ -30,7 +30,7 @@ module Zyphr
     end
 
     # Confirm email verification
-    # Verify the user&#39;s email using a token you collected yourself. IMPORTANT: the emailed verification LINK verifies the address server-side **on click** and then redirects to &#x60;redirect_url&#x60;. 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** (&#x60;200&#x60; with &#x60;already_verified: true&#x60;), not an error. Only a genuinely invalid / expired / unknown token returns &#x60;400&#x60;. &#x60;send&#x60; / &#x60;confirm&#x60; / &#x60;resend&#x60; are NOT a mandatory matched set — &#x60;confirm&#x60; is for flows where you collect the token directly rather than landing the hosted redirect. Recommended pattern for the redirect landing: call &#x60;confirm&#x60;, ignore its result, then read the user&#39;s verified state back and report that — correct whether or not the link already consumed the token.
+    # Verify the user&#39;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 &#x60;redirect_url&#x60; with &#x60;?token&#x3D;&lt;raw&gt;&#x60;; 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 &#x60;200&#x60; with &#x60;already_verified: true&#x60; rather than an error, so a double submit or a link opened twice is safe. Only a genuinely invalid / expired / unknown token returns &#x60;400&#x60;. Note &#x60;redirect_url&#x60; is REQUIRED (snake_case) when sending the verification email — there is no hosted fallback page.
     # @param confirm_email_verification_request [ConfirmEmailVerificationRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(ConfirmEmailVerificationResponse, Integer, Hash)>] ConfirmEmailVerificationResponse data, response status code and response headers

data/lib/zyphr/api/devices_api.rb

@@ -339,7 +339,7 @@ module Zyphr
     end
 
     # Register a device
-    # 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. 
     # @param register_device_request [RegisterDeviceRequest] 
     # @param [Hash] opts the optional parameters
     # @return [DeviceResponse]
@@ -349,7 +349,7 @@ module Zyphr
     end
 
     # Register a device
-    # 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. 
     # @param register_device_request [RegisterDeviceRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(DeviceResponse, Integer, Hash)>] DeviceResponse data, response status code and response headers
@@ -387,7 +387,7 @@ module Zyphr
       return_type = opts[:debug_return_type] || 'DeviceResponse'
 
       # auth_names
-      auth_names = opts[:debug_auth_names] || ['ApiKeyAuth']
+      auth_names = opts[:debug_auth_names] || ['ApplicationSecret', 'ApiKeyAuth', 'ApplicationPublicKey']
 
       new_options = opts.merge(
         :operation => :"DevicesApi.register_device",

data/spec/api/auth_email_verification_api_spec.rb

@@ -34,7 +34,7 @@ describe 'AuthEmailVerificationApi' do
 
   # unit tests for confirm_email_verification
   # Confirm email verification
-  # 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.
   # @param confirm_email_verification_request 
   # @param [Hash] opts the optional parameters
   # @return [ConfirmEmailVerificationResponse]

data/spec/api/devices_api_spec.rb

@@ -96,7 +96,7 @@ describe 'DevicesApi' do
 
   # unit tests for register_device
   # Register a device
-  # 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. 
   # @param register_device_request 
   # @param [Hash] opts the optional parameters
   # @return [DeviceResponse]

data/zyphr.gemspec

@@ -17,7 +17,7 @@ require "zyphr/version"
 
 Gem::Specification.new do |s|
   s.name        = "zyphr"
-  s.version = '0.1.57'
+  s.version = '0.1.59'
   s.platform    = Gem::Platform::RUBY
   s.authors     = ["Zyphr"]
   s.email       = ["support@zyphr.dev"]

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: zyphr
 version: !ruby/object:Gem::Version
-  version: 0.1.57
+  version: 0.1.59
 platform: ruby
 authors:
 - Zyphr
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2026-08-17 00:00:00.000000000 Z
+date: 2026-08-23 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: faraday