zyphr 0.1.37 → 0.1.38

data/spec/api/auth_registration_api_spec.rb

@@ -58,7 +58,7 @@ describe 'AuthRegistrationApi' do
 
   # unit tests for sign_in_anonymously
   # Sign in anonymously
-  # Issue an end-user identity to a device without email, password, OAuth, or any other credential. Idempotent per (application, environment, device_id): repeated calls with the same device_id return the same user but a fresh token pair. Prior sessions for the user remain valid until natural expiry.  Anonymous users do not count toward MAU quota until their first authenticated request after sign-in (excluding /v1/auth/refresh).  Convert an anonymous user to a full account via POST /v1/auth/users/convert. 
+  # Issue an end-user identity to a device without email, password, OAuth, or any other credential. Idempotent per (application, environment, device_id): repeated calls with the same device_id return the same user but a fresh token pair. Prior sessions for the user remain valid until natural expiry.  Anonymous users do not count toward MAU quota until their first authenticated request after sign-in (excluding /v1/auth/refresh).  Convert an anonymous user to a full account via POST /v1/auth/users/convert.  Pass an optional `organization_id` to create the anonymous user directly in an organization; the returned access token then carries `org_id` (and `orgs`), matching the org-scoped register/login flow. 
   # @param sign_in_anonymously_request 
   # @param [Hash] opts the optional parameters
   # @return [AuthResultResponse]
@@ -68,4 +68,16 @@ describe 'AuthRegistrationApi' do
     end
   end
 
+  # unit tests for sign_in_with_game_center
+  # Sign in with Apple Game Center
+  # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `gamePlayerID` and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+  # @param sign_in_with_game_center_request 
+  # @param [Hash] opts the optional parameters
+  # @return [AuthResultResponse]
+  describe 'sign_in_with_game_center test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
 end

data/spec/api/auth_user_directory_api_spec.rb

@@ -0,0 +1,136 @@
+=begin
+#Zyphr API
+
+#Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account's current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+
+The version of the OpenAPI document: 1.0.0
+Contact: support@zyphr.dev
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for Zyphr::AuthUserDirectoryApi
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'AuthUserDirectoryApi' do
+  before do
+    # run before each test
+    @api_instance = Zyphr::AuthUserDirectoryApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of AuthUserDirectoryApi' do
+    it 'should create an instance of AuthUserDirectoryApi' do
+      expect(@api_instance).to be_instance_of(Zyphr::AuthUserDirectoryApi)
+    end
+  end
+
+  # unit tests for delete_end_user_by_application
+  # Delete an end user (server-side admin)
+  # Secret-key-scoped admin soft-delete for an arbitrary end user in the authenticating application. Works in both test and live environments. Scoped to the application via the application_id filter — a caller can never delete a user belonging to another application.  Mirrors the self-service `DELETE /auth/users/me` flow: revokes all sessions, soft-deletes the row (status='deleted'), and emits a `user.deleted` webhook with `method='application_admin'`. The audit log row survives (no FK to end_users), so org-history queries still resolve. 
+  # @param user_id 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'delete_end_user_by_application test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for get_end_user_by_email
+  # Look up an end user by email (server-side admin)
+  # Secret-key-scoped lookup of a single end user by email address within the authenticating application. Scoped to the application — never resolves a user from another application. Does not return the password hash. 
+  # @param email 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'get_end_user_by_email test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for get_end_user_by_id
+  # Get an end user by id (server-side admin)
+  # Secret-key-scoped fetch of a single end user by id within the authenticating application. Scoped to the application — a caller can never read a user belonging to another application. 
+  # @param user_id 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'get_end_user_by_id test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for get_end_user_claims
+  # Get an end user's stored custom claims (server-side admin)
+  # Secret-key-scoped read of the authoritative custom_claims stored for an end user. These are the TRUSTED claims embedded into the user's JWTs on login/refresh — use them (not the client-writable `metadata` field) for authorization decisions. Returns an empty object when none are set. 
+  # @param user_id 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'get_end_user_claims test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for invite_end_user
+  # Pre-provision (invite) an end user (server-side admin)
+  # Secret-key-scoped pre-provisioning for an end user. Creates a passwordless user in the authenticating application (idempotent on email — an existing, non-deleted user is reused, not duplicated) and, when `send_link` is set, sends a first-login link so the user can set up their account without self-registration.  - `send_link: \"magic\"` sends a magic-link sign-in email. - `send_link: \"password_reset\"` sends a set-password email. - `send_link: \"none\"` (default) creates the user with no email.  A `redirect_url` is required when `send_link` is \"magic\" or \"password_reset\"; it must match the application's redirect_uris allowlist (custom schemes such as yourapp://path are permitted). 
+  # @param invite_end_user_request 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'invite_end_user test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for list_end_users
+  # List / search end users (server-side admin)
+  # Secret-key-scoped directory listing of end users in the authenticating application. Supports substring search over email, name, and phone, an optional environment filter (test/live), and pagination. Scoped to the application — never returns users from another application. 
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :page 
+  # @option opts [Integer] :per_page 
+  # @option opts [String] :search Substring match against email, name, or phone number.
+  # @option opts [String] :environment 
+  # @return [nil]
+  describe 'list_end_users test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for set_end_user_claims
+  # Set an end user's stored custom claims (server-side admin)
+  # Secret-key-scoped upsert of the authoritative custom_claims for an end user. Set server-side only — clients cannot write these, which is what makes them safe for authorization (e.g. an account-type/admin flag). Claims are embedded into the user's JWTs on the next login/refresh. Max 4KB; reserved JWT/Zyphr claim names are rejected.  To make a change take effect immediately on already-issued tokens (e.g. revoking admin), call POST /auth/sessions/revoke-all for the user after updating claims — that bumps the revocation epoch so outstanding access tokens stop verifying. 
+  # @param user_id 
+  # @param set_end_user_claims_request 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'set_end_user_claims test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for update_end_user_by_application
+  # Update an end user (server-side admin)
+  # Secret-key-scoped update of an arbitrary end user in the authenticating application. Updatable fields: email, name, avatar_url, metadata, status. Scoped to the application — a caller can never modify a user belonging to another application. 
+  # @param user_id 
+  # @param update_end_user_by_application_request 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'update_end_user_by_application test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+end

data/spec/api/auth_user_profile_api_spec.rb

@@ -43,18 +43,6 @@ describe 'AuthUserProfileApi' do
     end
   end
 
-  # unit tests for delete_end_user_by_application
-  # Delete an end user (test environment only)
-  # App-credentialed soft-delete for an end user, scoped to the test environment only. Live-mode credentials receive 403 — this is the intentional safety guard against a misconfigured CI runner nuking production users.  Mirrors the self-service `DELETE /auth/users/me` flow: revokes all sessions, soft-deletes the row (status='deleted'), and emits a `user.deleted` webhook with `method='application_admin'`. The audit log row survives (no FK to end_users), so org-history queries still resolve.  Intended for smoke / test-fixture cleanup. Production deletes should continue to use `DELETE /auth/users/me` from the end-user's own session or the dashboard. 
-  # @param user_id 
-  # @param [Hash] opts the optional parameters
-  # @return [nil]
-  describe 'delete_end_user_by_application test' do
-    it 'should work' do
-      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
-    end
-  end
-
   # unit tests for get_end_user
   # Get current end user profile
   # Retrieve the profile of the currently authenticated end user.

data/spec/models/invite_end_user_request_spec.rb

@@ -0,0 +1,64 @@
+=begin
+#Zyphr API
+
+#Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account's current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+
+The version of the OpenAPI document: 1.0.0
+Contact: support@zyphr.dev
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+require 'date'
+
+# Unit tests for Zyphr::InviteEndUserRequest
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::InviteEndUserRequest do
+  let(:instance) { Zyphr::InviteEndUserRequest.new }
+
+  describe 'test an instance of InviteEndUserRequest' do
+    it 'should create an instance of InviteEndUserRequest' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::InviteEndUserRequest)
+    end
+  end
+
+  describe 'test attribute "email"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "name"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "metadata"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "send_link"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["magic", "password_reset", "none"])
+      # validator.allowable_values.each do |value|
+      #   expect { instance.send_link = value }.not_to raise_error
+      # end
+    end
+  end
+
+  describe 'test attribute "redirect_url"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+end

data/spec/models/o_auth_provider_name_spec.rb

@@ -0,0 +1,30 @@
+=begin
+#Zyphr API
+
+#Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account's current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+
+The version of the OpenAPI document: 1.0.0
+Contact: support@zyphr.dev
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+require 'date'
+
+# Unit tests for Zyphr::OAuthProviderName
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::OAuthProviderName do
+  let(:instance) { Zyphr::OAuthProviderName.new }
+
+  describe 'test an instance of OAuthProviderName' do
+    it 'should create an instance of OAuthProviderName' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::OAuthProviderName)
+    end
+  end
+
+end

data/spec/models/set_end_user_claims_request_spec.rb

@@ -0,0 +1,36 @@
+=begin
+#Zyphr API
+
+#Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account's current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+
+The version of the OpenAPI document: 1.0.0
+Contact: support@zyphr.dev
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+require 'date'
+
+# Unit tests for Zyphr::SetEndUserClaimsRequest
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::SetEndUserClaimsRequest do
+  let(:instance) { Zyphr::SetEndUserClaimsRequest.new }
+
+  describe 'test an instance of SetEndUserClaimsRequest' do
+    it 'should create an instance of SetEndUserClaimsRequest' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::SetEndUserClaimsRequest)
+    end
+  end
+
+  describe 'test attribute "claims"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+end

data/spec/models/sign_in_anonymously_request_spec.rb

@@ -45,4 +45,16 @@ describe Zyphr::SignInAnonymouslyRequest do
     end
   end
 
+  describe 'test attribute "organization_id"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "organization_role"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
 end

data/spec/models/sign_in_with_game_center_request_spec.rb

@@ -0,0 +1,66 @@
+=begin
+#Zyphr API
+
+#Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account's current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+
+The version of the OpenAPI document: 1.0.0
+Contact: support@zyphr.dev
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+require 'date'
+
+# Unit tests for Zyphr::SignInWithGameCenterRequest
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::SignInWithGameCenterRequest do
+  let(:instance) { Zyphr::SignInWithGameCenterRequest.new }
+
+  describe 'test an instance of SignInWithGameCenterRequest' do
+    it 'should create an instance of SignInWithGameCenterRequest' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::SignInWithGameCenterRequest)
+    end
+  end
+
+  describe 'test attribute "player_id"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "public_key_url"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "signature"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "salt"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "timestamp"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "bundle_id"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+end

data/spec/models/update_end_user_by_application_request_spec.rb

@@ -0,0 +1,60 @@
+=begin
+#Zyphr API
+
+#Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account's current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+
+The version of the OpenAPI document: 1.0.0
+Contact: support@zyphr.dev
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+require 'date'
+
+# Unit tests for Zyphr::UpdateEndUserByApplicationRequest
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::UpdateEndUserByApplicationRequest do
+  let(:instance) { Zyphr::UpdateEndUserByApplicationRequest.new }
+
+  describe 'test an instance of UpdateEndUserByApplicationRequest' do
+    it 'should create an instance of UpdateEndUserByApplicationRequest' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::UpdateEndUserByApplicationRequest)
+    end
+  end
+
+  describe 'test attribute "email"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "name"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "avatar_url"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "metadata"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "status"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+end

data/zyphr.gemspec

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