zyphr 0.1.39 → 0.1.40

data/spec/api/workflows_api_spec.rb

@@ -0,0 +1,192 @@
+=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::WorkflowsApi
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'WorkflowsApi' do
+  before do
+    # run before each test
+    @api_instance = Zyphr::WorkflowsApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of WorkflowsApi' do
+    it 'should create an instance of WorkflowsApi' do
+      expect(@api_instance).to be_instance_of(Zyphr::WorkflowsApi)
+    end
+  end
+
+  # unit tests for add_workflow_step
+  # Add a workflow step
+  # Append a step to a workflow. Channel steps (`email`, `push`, `sms`, `in_app`, `slack`, `discord`, `teams`) carry message content in `config`; `delay` steps carry `{ amount, unit }`; `branch` steps carry `{ conditions }`. 
+  # @param key The workflow key.
+  # @param add_workflow_step_request 
+  # @param [Hash] opts the optional parameters
+  # @return [AddWorkflowStep201Response]
+  describe 'add_workflow_step 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 create_workflow
+  # Create a workflow
+  # Create a new notification workflow. A workflow is a named, multi-step notification sequence identified by a unique `key` within the project. If `key` is omitted, one is derived from the `name`. 
+  # @param create_workflow_request 
+  # @param [Hash] opts the optional parameters
+  # @return [CreateWorkflow201Response]
+  describe 'create_workflow 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 delete_workflow
+  # Delete a workflow
+  # Permanently delete a workflow and all of its steps.
+  # @param key The workflow key.
+  # @param [Hash] opts the optional parameters
+  # @return [DeleteWorkflow200Response]
+  describe 'delete_workflow 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 delete_workflow_step
+  # Delete a workflow step
+  # Remove a step from a workflow.
+  # @param key The workflow key.
+  # @param step_key The step key.
+  # @param [Hash] opts the optional parameters
+  # @return [DeleteWorkflowStep200Response]
+  describe 'delete_workflow_step 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_workflow
+  # Get a workflow
+  # Retrieve a single workflow by its key, including its ordered steps.
+  # @param key The workflow key.
+  # @param [Hash] opts the optional parameters
+  # @return [CreateWorkflow201Response]
+  describe 'get_workflow 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_workflow_executions
+  # List workflow executions
+  # List the executions of a workflow, most recent first. Supports pagination.
+  # @param key The workflow key.
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :page Page number (1-based).
+  # @option opts [Integer] :per_page Number of executions per page (max 100).
+  # @return [ListWorkflowExecutions200Response]
+  describe 'list_workflow_executions 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_workflows
+  # List workflows
+  # List workflows in the project. Supports pagination, free-text search, and status filtering.
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :page Page number (1-based).
+  # @option opts [Integer] :per_page Number of workflows per page (max 100).
+  # @option opts [String] :search Free-text search over workflow name and key.
+  # @option opts [WorkflowStatus] :status Filter by workflow status.
+  # @return [ListWorkflows200Response]
+  describe 'list_workflows 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 reorder_workflow_steps
+  # Reorder workflow steps
+  # Reorder a workflow's steps. Provide the full set of step keys in the desired order — the array must contain exactly the workflow's existing step keys. 
+  # @param key The workflow key.
+  # @param reorder_workflow_steps_request 
+  # @param [Hash] opts the optional parameters
+  # @return [CreateWorkflow201Response]
+  describe 'reorder_workflow_steps 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 trigger_workflow
+  # Trigger a workflow
+  # Trigger an execution of an active workflow for one or more recipients. The `to` field accepts a single recipient, an array of recipients, or a topic object (`{ \"topic\": \"topic-key\" }`) to trigger for all subscribers of a topic. One execution is created per resolved subscriber. 
+  # @param key The workflow key.
+  # @param trigger_workflow_request 
+  # @param [Hash] opts the optional parameters
+  # @return [TriggerWorkflow202Response]
+  describe 'trigger_workflow 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_workflow
+  # Update a workflow
+  # Update a workflow's metadata. Only the provided fields are changed. To change the status, use the dedicated status endpoint.
+  # @param key The workflow key.
+  # @param update_workflow_request 
+  # @param [Hash] opts the optional parameters
+  # @return [CreateWorkflow201Response]
+  describe 'update_workflow 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_workflow_status
+  # Update workflow status
+  # Change a workflow's lifecycle status. This is the single endpoint for activating, pausing, archiving, or returning a workflow to draft — there are no separate `/activate` or `/pause` endpoints. Set `status` to `active` to activate and `paused` to pause. 
+  # @param key The workflow key.
+  # @param update_workflow_status_request 
+  # @param [Hash] opts the optional parameters
+  # @return [CreateWorkflow201Response]
+  describe 'update_workflow_status 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_workflow_step
+  # Update a workflow step
+  # Update a step's name and/or config. Only the provided fields are changed.
+  # @param key The workflow key.
+  # @param step_key The step key.
+  # @param update_workflow_step_request 
+  # @param [Hash] opts the optional parameters
+  # @return [AddWorkflowStep201Response]
+  describe 'update_workflow_step 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/models/add_workflow_step201_response_spec.rb

@@ -0,0 +1,42 @@
+=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::AddWorkflowStep201Response
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::AddWorkflowStep201Response do
+  let(:instance) { Zyphr::AddWorkflowStep201Response.new }
+
+  describe 'test an instance of AddWorkflowStep201Response' do
+    it 'should create an instance of AddWorkflowStep201Response' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::AddWorkflowStep201Response)
+    end
+  end
+
+  describe 'test attribute "data"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "meta"' 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/add_workflow_step_request_spec.rb

@@ -0,0 +1,76 @@
+=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::AddWorkflowStepRequest
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::AddWorkflowStepRequest do
+  let(:instance) { Zyphr::AddWorkflowStepRequest.new }
+
+  describe 'test an instance of AddWorkflowStepRequest' do
+    it 'should create an instance of AddWorkflowStepRequest' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::AddWorkflowStepRequest)
+    end
+  end
+
+  describe 'test attribute "step_key"' 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 "type"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "position"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "config"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "parent_step_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 "branch_path"' 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', ["true", "false"])
+      # validator.allowable_values.each do |value|
+      #   expect { instance.branch_path = value }.not_to raise_error
+      # end
+    end
+  end
+
+end

data/spec/models/create_workflow201_response_spec.rb

@@ -0,0 +1,42 @@
+=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::CreateWorkflow201Response
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::CreateWorkflow201Response do
+  let(:instance) { Zyphr::CreateWorkflow201Response.new }
+
+  describe 'test an instance of CreateWorkflow201Response' do
+    it 'should create an instance of CreateWorkflow201Response' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::CreateWorkflow201Response)
+    end
+  end
+
+  describe 'test attribute "data"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "meta"' 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/{v1_muse_subjects_suggest_post_request_spec.rb → create_workflow_request_spec.rb}

@@ -14,42 +14,44 @@ require 'spec_helper'
 require 'json'
 require 'date'
 
-# Unit tests for Zyphr::V1MuseSubjectsSuggestPostRequest
+# Unit tests for Zyphr::CreateWorkflowRequest
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe Zyphr::V1MuseSubjectsSuggestPostRequest do
-  let(:instance) { Zyphr::V1MuseSubjectsSuggestPostRequest.new }
+describe Zyphr::CreateWorkflowRequest do
+  let(:instance) { Zyphr::CreateWorkflowRequest.new }
 
-  describe 'test an instance of V1MuseSubjectsSuggestPostRequest' do
-    it 'should create an instance of V1MuseSubjectsSuggestPostRequest' do
+  describe 'test an instance of CreateWorkflowRequest' do
+    it 'should create an instance of CreateWorkflowRequest' do
       # uncomment below to test the instance creation
-      #expect(instance).to be_instance_of(Zyphr::V1MuseSubjectsSuggestPostRequest)
+      #expect(instance).to be_instance_of(Zyphr::CreateWorkflowRequest)
     end
   end
 
-  describe 'test attribute "template_id"' do
+  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 "template_body"' do
+  describe 'test attribute "key"' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  describe 'test attribute "channel"' do
+  describe 'test attribute "description"' 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', ["email", "push"])
-      # validator.allowable_values.each do |value|
-      #   expect { instance.channel = value }.not_to raise_error
-      # end
     end
   end
 
-  describe 'test attribute "project_id"' do
+  describe 'test attribute "is_critical"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "tags"' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end

data/spec/models/{topic_delete_response_data_spec.rb → delete_workflow200_response_data_spec.rb}

@@ -14,16 +14,16 @@ require 'spec_helper'
 require 'json'
 require 'date'
 
-# Unit tests for Zyphr::TopicDeleteResponseData
+# Unit tests for Zyphr::DeleteWorkflow200ResponseData
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe Zyphr::TopicDeleteResponseData do
-  let(:instance) { Zyphr::TopicDeleteResponseData.new }
+describe Zyphr::DeleteWorkflow200ResponseData do
+  let(:instance) { Zyphr::DeleteWorkflow200ResponseData.new }
 
-  describe 'test an instance of TopicDeleteResponseData' do
-    it 'should create an instance of TopicDeleteResponseData' do
+  describe 'test an instance of DeleteWorkflow200ResponseData' do
+    it 'should create an instance of DeleteWorkflow200ResponseData' do
       # uncomment below to test the instance creation
-      #expect(instance).to be_instance_of(Zyphr::TopicDeleteResponseData)
+      #expect(instance).to be_instance_of(Zyphr::DeleteWorkflow200ResponseData)
     end
   end
 

data/spec/models/delete_workflow200_response_spec.rb

@@ -0,0 +1,42 @@
+=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::DeleteWorkflow200Response
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::DeleteWorkflow200Response do
+  let(:instance) { Zyphr::DeleteWorkflow200Response.new }
+
+  describe 'test an instance of DeleteWorkflow200Response' do
+    it 'should create an instance of DeleteWorkflow200Response' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::DeleteWorkflow200Response)
+    end
+  end
+
+  describe 'test attribute "data"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "meta"' 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/delete_workflow_step200_response_data_spec.rb

@@ -0,0 +1,48 @@
+=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::DeleteWorkflowStep200ResponseData
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::DeleteWorkflowStep200ResponseData do
+  let(:instance) { Zyphr::DeleteWorkflowStep200ResponseData.new }
+
+  describe 'test an instance of DeleteWorkflowStep200ResponseData' do
+    it 'should create an instance of DeleteWorkflowStep200ResponseData' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::DeleteWorkflowStep200ResponseData)
+    end
+  end
+
+  describe 'test attribute "workflow_key"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "step_key"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "deleted"' 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/delete_workflow_step200_response_spec.rb

@@ -0,0 +1,42 @@
+=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::DeleteWorkflowStep200Response
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::DeleteWorkflowStep200Response do
+  let(:instance) { Zyphr::DeleteWorkflowStep200Response.new }
+
+  describe 'test an instance of DeleteWorkflowStep200Response' do
+    it 'should create an instance of DeleteWorkflowStep200Response' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::DeleteWorkflowStep200Response)
+    end
+  end
+
+  describe 'test attribute "data"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "meta"' 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/{sms_list_response_meta_spec.rb → list_workflow_executions200_response_meta_spec.rb}

@@ -14,16 +14,16 @@ require 'spec_helper'
 require 'json'
 require 'date'
 
-# Unit tests for Zyphr::SmsListResponseMeta
+# Unit tests for Zyphr::ListWorkflowExecutions200ResponseMeta
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe Zyphr::SmsListResponseMeta do
-  let(:instance) { Zyphr::SmsListResponseMeta.new }
+describe Zyphr::ListWorkflowExecutions200ResponseMeta do
+  let(:instance) { Zyphr::ListWorkflowExecutions200ResponseMeta.new }
 
-  describe 'test an instance of SmsListResponseMeta' do
-    it 'should create an instance of SmsListResponseMeta' do
+  describe 'test an instance of ListWorkflowExecutions200ResponseMeta' do
+    it 'should create an instance of ListWorkflowExecutions200ResponseMeta' do
       # uncomment below to test the instance creation
-      #expect(instance).to be_instance_of(Zyphr::SmsListResponseMeta)
+      #expect(instance).to be_instance_of(Zyphr::ListWorkflowExecutions200ResponseMeta)
     end
   end
 

data/spec/models/list_workflow_executions200_response_spec.rb

@@ -0,0 +1,42 @@
+=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::ListWorkflowExecutions200Response
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zyphr::ListWorkflowExecutions200Response do
+  let(:instance) { Zyphr::ListWorkflowExecutions200Response.new }
+
+  describe 'test an instance of ListWorkflowExecutions200Response' do
+    it 'should create an instance of ListWorkflowExecutions200Response' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zyphr::ListWorkflowExecutions200Response)
+    end
+  end
+
+  describe 'test attribute "data"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "meta"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+end