zyphr 0.1.36 → 0.1.38

data/docs/AuthUserProfileApi.md

@@ -5,7 +5,6 @@ All URIs are relative to *https://api.zyphr.dev/v1*
 | Method | HTTP request | Description |
 | ------ | ------------ | ----------- |
 | [**delete_end_user**](AuthUserProfileApi.md#delete_end_user) | **DELETE** /auth/users/me | Delete current end user account |
-| [**delete_end_user_by_application**](AuthUserProfileApi.md#delete_end_user_by_application) | **DELETE** /auth/users/{user_id} | Delete an end user (test environment only) |
 | [**get_end_user**](AuthUserProfileApi.md#get_end_user) | **GET** /auth/users/me | Get current end user profile |
 | [**update_end_user**](AuthUserProfileApi.md#update_end_user) | **PATCH** /auth/users/me | Update current end user profile |
 
@@ -81,81 +80,6 @@ This endpoint does not need any parameter.
 - **Accept**: application/json
 
 
-## delete_end_user_by_application
-
-> delete_end_user_by_application(user_id)
-
-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. 
-
-### Examples
-
-```ruby
-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: 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::AuthUserProfileApi.new
-user_id = '38400000-8cf0-11bd-b23e-10b96e4ef00d' # String | 
-
-begin
-  # Delete an end user (test environment only)
-  api_instance.delete_end_user_by_application(user_id)
-rescue Zyphr::ApiError => e
-  puts "Error when calling AuthUserProfileApi->delete_end_user_by_application: #{e}"
-end
-```
-
-#### Using the delete_end_user_by_application_with_http_info variant
-
-This returns an Array which contains the response data (`nil` in this case), status code and headers.
-
-> <Array(nil, Integer, Hash)> delete_end_user_by_application_with_http_info(user_id)
-
-```ruby
-begin
-  # Delete an end user (test environment only)
-  data, status_code, headers = api_instance.delete_end_user_by_application_with_http_info(user_id)
-  p status_code # => 2xx
-  p headers # => { ... }
-  p data # => nil
-rescue Zyphr::ApiError => e
-  puts "Error when calling AuthUserProfileApi->delete_end_user_by_application_with_http_info: #{e}"
-end
-```
-
-### Parameters
-
-| Name | Type | Description | Notes |
-| ---- | ---- | ----------- | ----- |
-| **user_id** | **String** |  |  |
-
-### Return type
-
-nil (empty response body)
-
-### Authorization
-
-[ApplicationSecret](../README.md#ApplicationSecret), [ApplicationPublicKey](../README.md#ApplicationPublicKey)
-
-### HTTP request headers
-
-- **Content-Type**: Not defined
-- **Accept**: Not defined
-
-
 ## get_end_user
 
 > <AuthUserResponse> get_end_user

data/docs/InviteEndUserRequest.md

@@ -0,0 +1,26 @@
+# Zyphr::InviteEndUserRequest
+
+## Properties
+
+| Name | Type | Description | Notes |
+| ---- | ---- | ----------- | ----- |
+| **email** | **String** |  |  |
+| **name** | **String** |  | [optional] |
+| **metadata** | **Object** |  | [optional] |
+| **send_link** | **String** |  | [optional][default to 'none'] |
+| **redirect_url** | **String** |  | [optional] |
+
+## Example
+
+```ruby
+require 'zyphr'
+
+instance = Zyphr::InviteEndUserRequest.new(
+  email: null,
+  name: null,
+  metadata: null,
+  send_link: null,
+  redirect_url: null
+)
+```
+

data/docs/OAuthProviderName.md

@@ -0,0 +1,15 @@
+# Zyphr::OAuthProviderName
+
+## Properties
+
+| Name | Type | Description | Notes |
+| ---- | ---- | ----------- | ----- |
+
+## Example
+
+```ruby
+require 'zyphr'
+
+instance = Zyphr::OAuthProviderName.new()
+```
+

data/docs/SendTemplateTestEmailRequest.md

@@ -0,0 +1,20 @@
+# Zyphr::SendTemplateTestEmailRequest
+
+## Properties
+
+| Name | Type | Description | Notes |
+| ---- | ---- | ----------- | ----- |
+| **to** | **String** |  |  |
+| **variables** | **Hash<String, Object>** |  | [optional] |
+
+## Example
+
+```ruby
+require 'zyphr'
+
+instance = Zyphr::SendTemplateTestEmailRequest.new(
+  to: null,
+  variables: null
+)
+```
+

data/docs/SetEndUserClaimsRequest.md

@@ -0,0 +1,18 @@
+# Zyphr::SetEndUserClaimsRequest
+
+## Properties
+
+| Name | Type | Description | Notes |
+| ---- | ---- | ----------- | ----- |
+| **claims** | **Object** |  | [optional] |
+
+## Example
+
+```ruby
+require 'zyphr'
+
+instance = Zyphr::SetEndUserClaimsRequest.new(
+  claims: null
+)
+```
+

data/docs/SignInAnonymouslyRequest.md

@@ -7,6 +7,8 @@
 | **device_id** | **String** | Stable per-device identifier supplied by the client. Use a cryptographically-random opaque value persisted to client storage on first run. |  |
 | **name** | **String** | Optional display name. If omitted, the user has no name until conversion. | [optional] |
 | **metadata** | **Hash<String, Object>** |  | [optional] |
+| **organization_id** | **String** | Optional organization to scope the anonymous user into. Must exist in the key's environment. When set, the returned token carries org_id and orgs. | [optional] |
+| **organization_role** | **String** | Optional membership role for the org add. Requires organization_id. Opaque, up to 80 characters. | [optional] |
 
 ## Example
 
@@ -16,7 +18,9 @@ require 'zyphr'
 instance = Zyphr::SignInAnonymouslyRequest.new(
   device_id: null,
   name: null,
-  metadata: null
+  metadata: null,
+  organization_id: null,
+  organization_role: null
 )
 ```
 

data/docs/SignInWithGameCenterRequest.md

@@ -0,0 +1,28 @@
+# Zyphr::SignInWithGameCenterRequest
+
+## Properties
+
+| Name | Type | Description | Notes |
+| ---- | ---- | ----------- | ----- |
+| **player_id** | **String** | The modern scoped gamePlayerID from GKLocalPlayer (NOT the deprecated legacy playerID). |  |
+| **public_key_url** | **String** | Apple-supplied URL to the public-key certificate. Must be https on an apple.com host; server-side SSRF-guarded before fetch. |  |
+| **signature** | **String** | Base64-encoded RSA signature returned by GameKit. |  |
+| **salt** | **String** | Base64-encoded salt bytes returned by GameKit. |  |
+| **timestamp** | **Float** | Apple-supplied timestamp (epoch milliseconds) returned by GameKit. |  |
+| **bundle_id** | **String** | The iOS bundle identifier the assertion was generated for. Must match a bundle id configured on the application's Game Center provider. |  |
+
+## Example
+
+```ruby
+require 'zyphr'
+
+instance = Zyphr::SignInWithGameCenterRequest.new(
+  player_id: null,
+  public_key_url: null,
+  signature: null,
+  salt: null,
+  timestamp: null,
+  bundle_id: null
+)
+```
+

data/docs/TemplatesApi.md

@@ -9,6 +9,7 @@ All URIs are relative to *https://api.zyphr.dev/v1*
 | [**get_template**](TemplatesApi.md#get_template) | **GET** /templates/{id} | Get template |
 | [**list_templates**](TemplatesApi.md#list_templates) | **GET** /templates | List templates |
 | [**render_template**](TemplatesApi.md#render_template) | **POST** /templates/{id}/render | Render template |
+| [**send_template_test_email**](TemplatesApi.md#send_template_test_email) | **POST** /templates/{id}/test | Send a test email using a template |
 | [**update_template**](TemplatesApi.md#update_template) | **PUT** /templates/{id} | Update template |
 
 
@@ -373,6 +374,76 @@ end
 - **Accept**: application/json
 
 
+## send_template_test_email
+
+> send_template_test_email(id, send_template_test_email_request)
+
+Send a test email using a template
+
+Render the template and send a one-off test email (dashboard JWT auth). Because this is a send-capable endpoint, a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`. 
+
+### Examples
+
+```ruby
+require 'time'
+require 'zyphr'
+# setup authorization
+Zyphr.configure do |config|
+  # Configure Bearer authorization (JWT): DashboardAuth
+  config.access_token = 'YOUR_BEARER_TOKEN'
+end
+
+api_instance = Zyphr::TemplatesApi.new
+id = '38400000-8cf0-11bd-b23e-10b96e4ef00d' # String | 
+send_template_test_email_request = Zyphr::SendTemplateTestEmailRequest.new({to: 'to_example'}) # SendTemplateTestEmailRequest | 
+
+begin
+  # Send a test email using a template
+  api_instance.send_template_test_email(id, send_template_test_email_request)
+rescue Zyphr::ApiError => e
+  puts "Error when calling TemplatesApi->send_template_test_email: #{e}"
+end
+```
+
+#### Using the send_template_test_email_with_http_info variant
+
+This returns an Array which contains the response data (`nil` in this case), status code and headers.
+
+> <Array(nil, Integer, Hash)> send_template_test_email_with_http_info(id, send_template_test_email_request)
+
+```ruby
+begin
+  # Send a test email using a template
+  data, status_code, headers = api_instance.send_template_test_email_with_http_info(id, send_template_test_email_request)
+  p status_code # => 2xx
+  p headers # => { ... }
+  p data # => nil
+rescue Zyphr::ApiError => e
+  puts "Error when calling TemplatesApi->send_template_test_email_with_http_info: #{e}"
+end
+```
+
+### Parameters
+
+| Name | Type | Description | Notes |
+| ---- | ---- | ----------- | ----- |
+| **id** | **String** |  |  |
+| **send_template_test_email_request** | [**SendTemplateTestEmailRequest**](SendTemplateTestEmailRequest.md) |  |  |
+
+### Return type
+
+nil (empty response body)
+
+### Authorization
+
+[DashboardAuth](../README.md#DashboardAuth)
+
+### HTTP request headers
+
+- **Content-Type**: application/json
+- **Accept**: application/json
+
+
 ## update_template
 
 > <TemplateResponse> update_template(id, update_template_request)

data/docs/UpdateEndUserByApplicationRequest.md

@@ -0,0 +1,26 @@
+# Zyphr::UpdateEndUserByApplicationRequest
+
+## Properties
+
+| Name | Type | Description | Notes |
+| ---- | ---- | ----------- | ----- |
+| **email** | **String** |  | [optional] |
+| **name** | **String** |  | [optional] |
+| **avatar_url** | **String** |  | [optional] |
+| **metadata** | **Object** |  | [optional] |
+| **status** | **String** |  | [optional] |
+
+## Example
+
+```ruby
+require 'zyphr'
+
+instance = Zyphr::UpdateEndUserByApplicationRequest.new(
+  email: null,
+  name: null,
+  avatar_url: null,
+  metadata: null,
+  status: null
+)
+```
+

data/lib/zyphr/api/auth_email_otp_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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

data/lib/zyphr/api/auth_email_templates_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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

data/lib/zyphr/api/auth_email_verification_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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

data/lib/zyphr/api/auth_login_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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

data/lib/zyphr/api/auth_magic_links_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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

data/lib/zyphr/api/auth_mfa_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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

data/lib/zyphr/api/auth_o_auth_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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
@@ -21,7 +21,7 @@ module Zyphr
     end
     # Disconnect OAuth provider
     # Disconnect an OAuth provider from the current user.
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param [Hash] opts the optional parameters
     # @return [SuccessResult]
     def disconnect_o_auth_provider(provider, opts = {})
@@ -31,7 +31,7 @@ module Zyphr
 
     # Disconnect OAuth provider
     # Disconnect an OAuth provider from the current user.
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param [Hash] opts the optional parameters
     # @return [Array<(SuccessResult, Integer, Hash)>] SuccessResult data, response status code and response headers
     def disconnect_o_auth_provider_with_http_info(provider, opts = {})
@@ -84,7 +84,7 @@ module Zyphr
 
     # Get OAuth authorization URL
     # Generate an OAuth authorization URL for the specified provider.
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param redirect_uri [String] Redirect URI after authorization
     # @param [Hash] opts the optional parameters
     # @return [OAuthAuthorizationUrlResponse]
@@ -95,7 +95,7 @@ module Zyphr
 
     # Get OAuth authorization URL
     # Generate an OAuth authorization URL for the specified provider.
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param redirect_uri [String] Redirect URI after authorization
     # @param [Hash] opts the optional parameters
     # @return [Array<(OAuthAuthorizationUrlResponse, Integer, Hash)>] OAuthAuthorizationUrlResponse data, response status code and response headers
@@ -154,7 +154,7 @@ module Zyphr
 
     # Get OAuth connection info
     # Get OAuth connection info for a specific provider (without tokens). Safe for public key authentication.
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param [Hash] opts the optional parameters
     # @return [OAuthConnectionInfoResponse]
     def get_o_auth_connection_info(provider, opts = {})
@@ -164,7 +164,7 @@ module Zyphr
 
     # Get OAuth connection info
     # Get OAuth connection info for a specific provider (without tokens). Safe for public key authentication.
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param [Hash] opts the optional parameters
     # @return [Array<(OAuthConnectionInfoResponse, Integer, Hash)>] OAuthConnectionInfoResponse data, response status code and response headers
     def get_o_auth_connection_info_with_http_info(provider, opts = {})
@@ -217,7 +217,7 @@ module Zyphr
 
     # Get OAuth provider tokens
     # Get OAuth provider tokens for an end user. Requires secret key authentication (server-side only). This allows developers to access downstream APIs on behalf of their users. 
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param user_id [String] End user ID
     # @param [Hash] opts the optional parameters
     # @return [OAuthTokensResponse]
@@ -228,7 +228,7 @@ module Zyphr
 
     # Get OAuth provider tokens
     # Get OAuth provider tokens for an end user. Requires secret key authentication (server-side only). This allows developers to access downstream APIs on behalf of their users. 
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param user_id [String] End user ID
     # @param [Hash] opts the optional parameters
     # @return [Array<(OAuthTokensResponse, Integer, Hash)>] OAuthTokensResponse data, response status code and response headers
@@ -287,7 +287,7 @@ module Zyphr
 
     # Handle OAuth callback
     # Handle the OAuth callback by exchanging the authorization code for tokens and authenticating the user.
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param o_auth_callback_request [OAuthCallbackRequest] 
     # @param [Hash] opts the optional parameters
     # @return [OAuthCallbackResponse]
@@ -298,7 +298,7 @@ module Zyphr
 
     # Handle OAuth callback
     # Handle the OAuth callback by exchanging the authorization code for tokens and authenticating the user.
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param o_auth_callback_request [OAuthCallbackRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(OAuthCallbackResponse, Integer, Hash)>] OAuthCallbackResponse data, response status code and response headers
@@ -475,7 +475,7 @@ module Zyphr
 
     # Refresh OAuth provider tokens
     # Refresh OAuth provider tokens for an end user. Requires secret key authentication (server-side only). Only supported for providers that support token refresh (e.g., Google, Microsoft). 
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param refresh_o_auth_tokens_request [RefreshOAuthTokensRequest] 
     # @param [Hash] opts the optional parameters
     # @return [OAuthTokensRefreshResponse]
@@ -486,7 +486,7 @@ module Zyphr
 
     # Refresh OAuth provider tokens
     # Refresh OAuth provider tokens for an end user. Requires secret key authentication (server-side only). Only supported for providers that support token refresh (e.g., Google, Microsoft). 
-    # @param provider [String] OAuth provider name
+    # @param provider [OAuthProviderName] OAuth provider name
     # @param refresh_o_auth_tokens_request [RefreshOAuthTokensRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(OAuthTokensRefreshResponse, Integer, Hash)>] OAuthTokensRefreshResponse data, response status code and response headers

data/lib/zyphr/api/auth_organizations_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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

data/lib/zyphr/api/auth_password_reset_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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

data/lib/zyphr/api/auth_phone_api.rb

@@ -1,7 +1,7 @@
 =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  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#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