zyphr 0.1.56 → 0.1.58

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: de2fcdf8ab6779134bd46363a7c5fc6b458c05c72444a679bf6f0feba7de9bbd
-  data.tar.gz: 792f4f9353a0f31fd809afbcde76127e1a02e10f84ebc67236d33cc53e843e4d
+  metadata.gz: 73209ffa1ba9676a583e467516b494c43208a18f87c6a51ff66cf94a136cffb3
+  data.tar.gz: 5697da2a7c2ea0f6b7441c4a0912f1b034ae45e03271a99c5de9a39cb0d0e733
 SHA512:
-  metadata.gz: 700ea510741ee07471d0cc8d8128dcfed02f39b84df08eb6dd92bcaadd666d99176cd46b885e5296b751e86a96c4b8e2ec5c185ffc94e3ac55931a5934a6fc85
-  data.tar.gz: aa49c456517da6f54590d7c0fe374721b93875e4dfee83032b1b20553aa2f4260811a0484470e6e80dae518a43af092718ba5b2582d5ab3183ba0ac58d4ae896
+  metadata.gz: b7f63e08054d7f0e8949dd0caea18c48cb28a32374cf3ca23ba4f87ebefc27f05d31a88b682990b711b87eb6071290a0e33530e0c2e193830d7c81fd43892be3
+  data.tar.gz: 66cadb733a76634cfbf5e1e579cb0f5aff4208d0854780bf33e6a998c07cc903c940852bf924a686dcf538ef334d6d547d27d70313241014cffe694196f93a50

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. 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. 
 
 ### Examples
 

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. 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. 
     # @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. 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. 
     # @param register_device_request [RegisterDeviceRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(DeviceResponse, Integer, Hash)>] DeviceResponse data, response status code and response headers

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. 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. 
   # @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.56'
+  s.version = '0.1.58'
   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.56
+  version: 0.1.58
 platform: ruby
 authors:
 - Zyphr
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2026-08-16 00:00:00.000000000 Z
+date: 2026-08-19 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: faraday