incident_io_sdk 0.1.0

data/spec/api/incident_statuses_v1_api_spec.rb

@@ -0,0 +1,95 @@
+=begin
+#incident.io
+
+#This is the API reference for incident.io.  It documents available API endpoints, provides examples of how to use it, and instructions around things like authentication and error handling.  The API is hosted at:  - https://api.incident.io/  And you will need to create an API key via your [incident.io dashboard](https://app.incident.io/settings/api-keys) to make requests.  # Making requests  Here are the key concepts required to make requests to the incident.io API.  ## Authentication  For all requests made to the incident.io API, you'll need an API key.  To create an API key, head to the incident dashboard and visit [API keys](https://app.incident.io/settings/api-keys). When you create the key, you'll be able to choose what actions it can take for your account: choose carefully, as those roles can only be set when you first create the key. We'll only show you the token once, so make sure you store it somewhere safe.  API keys are global to your incident.io account, and can be managed by anyone who has the right permissions. We display the user that created the API key, and the API key will remain valid if that user becomes deactivated.  Once you have the key, you should make requests to the API that set the `Authorization` request header using a \"Bearer\" authentication scheme:  ``` Authorization: Bearer <YOUR_API_KEY> ```  ## Rate Limits  The incident.io API enforces rate limits to ensure consistent performance for all users.  The default rate limit is 1200 requests/minute per API key. This limit applies to most endpoints across the API.  Some endpoints have lower rate limits, particularly those that interact with external third-party systems that impose their own limitations. These specific limits vary by endpoint, and we recommend relying on the rate-limit error responses to understand usage patterns and implement appropriate retry strategies.  When you exceed a rate limit, the API will respond with a `429 Too Many Requests` status code, along with a JSON response that includes information about the limit and when you can retry:  ```json {     \"type\": \"too_many_requests\",     \"status\": 429,     \"request_id\": \"b839a403-7704-41c1-bf6a-39a2d68caefa\",     \"rate_limit\": {         \"name\": \"api_key_name\",         \"limit\": 1200,         \"remaining\": 0,         \"retry_after\": \"Thu, 17 Apr 2025 11:17:18 UTC\"     },     \"errors\": [         {             \"code\": \"too_many_requests\",             \"message\": \"Too many requests hit the API too quickly. We recommend an exponential backoff of your requests.\"         }     ] } ```  The response includes: * The name of the API key (`name`) * The bucket limit (`limit`) * The number of requests remaining (`remaining`) * When you can retry requests (`retry_after`)  ## Errors  We use standard HTTP response codes to indicate the status or failure of API requests.  The API response body will be JSON, and contain more detailed information on the nature of the error.  An example error when a request is made without an API key:  ```json {   \"type\": \"authentication_error\",   \"status\": 401,   \"request_id\": \"8e3cc412-b49d-4957-9073-2c19d2c61804\",   \"errors\": [     {       \"code\": \"missing_authorization_material\",       \"message\": \"No authorization material provided in request\"     }   ] } ```  Note that the error:  - Contains the HTTP status (`401`) - References the type of error (`authentication_error`) - Includes a `request_id` that can be provided to incident.io support to help  debug questions with your API request - Provides a list of individual errors, which go into detail about why the error  occurred  The most common error will be a 422 Validation Error, which is returned when the request was rejected due to failing validations.  These errors look like this:  ```json {   \"type\": \"validation_error\",   \"status\": 422,   \"request_id\": \"631766c4-4afd-4803-997c-cd700928fa4b\",   \"errors\": [     {       \"code\": \"is_required\",       \"message\": \"A severity is required to open an incident\",       \"source\": {         \"field\": \"severity_id\"       }     }   ] } ```  This error is caused by not providing a severity identifier, which should be at the `severity_id` field of the request payload. Errors like these can be mapped to forms, should you be integrating with the API from a user-interface.  ## Compatibility  We won't make breaking changes to existing API services or endpoints, but will expect integrators to upgrade themselves to the latest API endpoints within 3 months of us deprecating the old service.  We will make changes that are considered backwards compatible, which include:  - Adding new API endpoints and services - Adding new properties to responses from existing API endpoints - Reordering properties returned from existing API endpoints - Adding optional request parameters to existing API endpoints - Altering the format or length of IDs - Adding new values to enums  It is important that clients are robust to these changes, to ensure reliable integrations.  As an example, if you are generating a client using an openapi-generator, ensure the generated client is configured to support unknown enum values, often configured via the `enumUnknownDefaultCase` parameter.  When breaking changes are unavoidable, we'll create a new service version on a separate path, and run them in parallel.  For example:  - https://api.incident.io/v1/incidents - https://api.incident.io/v2/incidents  For any questions, email support@incident.io. 
+
+The version of the OpenAPI document: 1.0.0
+
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for IncidentIoSdk::IncidentStatusesV1Api
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'IncidentStatusesV1Api' do
+  before do
+    # run before each test
+    @api_instance = IncidentIoSdk::IncidentStatusesV1Api.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of IncidentStatusesV1Api' do
+    it 'should create an instance of IncidentStatusesV1Api' do
+      expect(@api_instance).to be_instance_of(IncidentIoSdk::IncidentStatusesV1Api)
+    end
+  end
+
+  # unit tests for incident_statuses_v1_create
+  # Create Incident Statuses V1
+  # Create a new incident status
+  # @param incident_statuses_create_payload_v1 
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentStatusesCreateResultV1]
+  describe 'incident_statuses_v1_create 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 incident_statuses_v1_delete
+  # Delete Incident Statuses V1
+  # Delete an incident status
+  # @param id Unique ID of this incident status
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'incident_statuses_v1_delete 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 incident_statuses_v1_list
+  # List Incident Statuses V1
+  # List all incident statuses for an organisation.
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentStatusesListResultV1]
+  describe 'incident_statuses_v1_list 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 incident_statuses_v1_show
+  # Show Incident Statuses V1
+  # Get a single incident status.
+  # @param id Unique ID of this incident status
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentStatusesShowResultV1]
+  describe 'incident_statuses_v1_show 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 incident_statuses_v1_update
+  # Update Incident Statuses V1
+  # Update an existing incident status
+  # @param id Unique ID of this incident status
+  # @param incident_statuses_update_payload_v1 
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentStatusesUpdateResultV1]
+  describe 'incident_statuses_v1_update 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/incident_timestamps_v2_api_spec.rb

@@ -0,0 +1,58 @@
+=begin
+#incident.io
+
+#This is the API reference for incident.io.  It documents available API endpoints, provides examples of how to use it, and instructions around things like authentication and error handling.  The API is hosted at:  - https://api.incident.io/  And you will need to create an API key via your [incident.io dashboard](https://app.incident.io/settings/api-keys) to make requests.  # Making requests  Here are the key concepts required to make requests to the incident.io API.  ## Authentication  For all requests made to the incident.io API, you'll need an API key.  To create an API key, head to the incident dashboard and visit [API keys](https://app.incident.io/settings/api-keys). When you create the key, you'll be able to choose what actions it can take for your account: choose carefully, as those roles can only be set when you first create the key. We'll only show you the token once, so make sure you store it somewhere safe.  API keys are global to your incident.io account, and can be managed by anyone who has the right permissions. We display the user that created the API key, and the API key will remain valid if that user becomes deactivated.  Once you have the key, you should make requests to the API that set the `Authorization` request header using a \"Bearer\" authentication scheme:  ``` Authorization: Bearer <YOUR_API_KEY> ```  ## Rate Limits  The incident.io API enforces rate limits to ensure consistent performance for all users.  The default rate limit is 1200 requests/minute per API key. This limit applies to most endpoints across the API.  Some endpoints have lower rate limits, particularly those that interact with external third-party systems that impose their own limitations. These specific limits vary by endpoint, and we recommend relying on the rate-limit error responses to understand usage patterns and implement appropriate retry strategies.  When you exceed a rate limit, the API will respond with a `429 Too Many Requests` status code, along with a JSON response that includes information about the limit and when you can retry:  ```json {     \"type\": \"too_many_requests\",     \"status\": 429,     \"request_id\": \"b839a403-7704-41c1-bf6a-39a2d68caefa\",     \"rate_limit\": {         \"name\": \"api_key_name\",         \"limit\": 1200,         \"remaining\": 0,         \"retry_after\": \"Thu, 17 Apr 2025 11:17:18 UTC\"     },     \"errors\": [         {             \"code\": \"too_many_requests\",             \"message\": \"Too many requests hit the API too quickly. We recommend an exponential backoff of your requests.\"         }     ] } ```  The response includes: * The name of the API key (`name`) * The bucket limit (`limit`) * The number of requests remaining (`remaining`) * When you can retry requests (`retry_after`)  ## Errors  We use standard HTTP response codes to indicate the status or failure of API requests.  The API response body will be JSON, and contain more detailed information on the nature of the error.  An example error when a request is made without an API key:  ```json {   \"type\": \"authentication_error\",   \"status\": 401,   \"request_id\": \"8e3cc412-b49d-4957-9073-2c19d2c61804\",   \"errors\": [     {       \"code\": \"missing_authorization_material\",       \"message\": \"No authorization material provided in request\"     }   ] } ```  Note that the error:  - Contains the HTTP status (`401`) - References the type of error (`authentication_error`) - Includes a `request_id` that can be provided to incident.io support to help  debug questions with your API request - Provides a list of individual errors, which go into detail about why the error  occurred  The most common error will be a 422 Validation Error, which is returned when the request was rejected due to failing validations.  These errors look like this:  ```json {   \"type\": \"validation_error\",   \"status\": 422,   \"request_id\": \"631766c4-4afd-4803-997c-cd700928fa4b\",   \"errors\": [     {       \"code\": \"is_required\",       \"message\": \"A severity is required to open an incident\",       \"source\": {         \"field\": \"severity_id\"       }     }   ] } ```  This error is caused by not providing a severity identifier, which should be at the `severity_id` field of the request payload. Errors like these can be mapped to forms, should you be integrating with the API from a user-interface.  ## Compatibility  We won't make breaking changes to existing API services or endpoints, but will expect integrators to upgrade themselves to the latest API endpoints within 3 months of us deprecating the old service.  We will make changes that are considered backwards compatible, which include:  - Adding new API endpoints and services - Adding new properties to responses from existing API endpoints - Reordering properties returned from existing API endpoints - Adding optional request parameters to existing API endpoints - Altering the format or length of IDs - Adding new values to enums  It is important that clients are robust to these changes, to ensure reliable integrations.  As an example, if you are generating a client using an openapi-generator, ensure the generated client is configured to support unknown enum values, often configured via the `enumUnknownDefaultCase` parameter.  When breaking changes are unavoidable, we'll create a new service version on a separate path, and run them in parallel.  For example:  - https://api.incident.io/v1/incidents - https://api.incident.io/v2/incidents  For any questions, email support@incident.io. 
+
+The version of the OpenAPI document: 1.0.0
+
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for IncidentIoSdk::IncidentTimestampsV2Api
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'IncidentTimestampsV2Api' do
+  before do
+    # run before each test
+    @api_instance = IncidentIoSdk::IncidentTimestampsV2Api.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of IncidentTimestampsV2Api' do
+    it 'should create an instance of IncidentTimestampsV2Api' do
+      expect(@api_instance).to be_instance_of(IncidentIoSdk::IncidentTimestampsV2Api)
+    end
+  end
+
+  # unit tests for incident_timestamps_v2_list
+  # List Incident Timestamps V2
+  # List all incident timestamps for an organisation.
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentTimestampsListResultV2]
+  describe 'incident_timestamps_v2_list 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 incident_timestamps_v2_show
+  # Show Incident Timestamps V2
+  # Get a single incident timestamp.
+  # @param id Unique ID of this incident timestamp
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentTimestampsShowResultV2]
+  describe 'incident_timestamps_v2_show 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/incident_types_v1_api_spec.rb

@@ -0,0 +1,58 @@
+=begin
+#incident.io
+
+#This is the API reference for incident.io.  It documents available API endpoints, provides examples of how to use it, and instructions around things like authentication and error handling.  The API is hosted at:  - https://api.incident.io/  And you will need to create an API key via your [incident.io dashboard](https://app.incident.io/settings/api-keys) to make requests.  # Making requests  Here are the key concepts required to make requests to the incident.io API.  ## Authentication  For all requests made to the incident.io API, you'll need an API key.  To create an API key, head to the incident dashboard and visit [API keys](https://app.incident.io/settings/api-keys). When you create the key, you'll be able to choose what actions it can take for your account: choose carefully, as those roles can only be set when you first create the key. We'll only show you the token once, so make sure you store it somewhere safe.  API keys are global to your incident.io account, and can be managed by anyone who has the right permissions. We display the user that created the API key, and the API key will remain valid if that user becomes deactivated.  Once you have the key, you should make requests to the API that set the `Authorization` request header using a \"Bearer\" authentication scheme:  ``` Authorization: Bearer <YOUR_API_KEY> ```  ## Rate Limits  The incident.io API enforces rate limits to ensure consistent performance for all users.  The default rate limit is 1200 requests/minute per API key. This limit applies to most endpoints across the API.  Some endpoints have lower rate limits, particularly those that interact with external third-party systems that impose their own limitations. These specific limits vary by endpoint, and we recommend relying on the rate-limit error responses to understand usage patterns and implement appropriate retry strategies.  When you exceed a rate limit, the API will respond with a `429 Too Many Requests` status code, along with a JSON response that includes information about the limit and when you can retry:  ```json {     \"type\": \"too_many_requests\",     \"status\": 429,     \"request_id\": \"b839a403-7704-41c1-bf6a-39a2d68caefa\",     \"rate_limit\": {         \"name\": \"api_key_name\",         \"limit\": 1200,         \"remaining\": 0,         \"retry_after\": \"Thu, 17 Apr 2025 11:17:18 UTC\"     },     \"errors\": [         {             \"code\": \"too_many_requests\",             \"message\": \"Too many requests hit the API too quickly. We recommend an exponential backoff of your requests.\"         }     ] } ```  The response includes: * The name of the API key (`name`) * The bucket limit (`limit`) * The number of requests remaining (`remaining`) * When you can retry requests (`retry_after`)  ## Errors  We use standard HTTP response codes to indicate the status or failure of API requests.  The API response body will be JSON, and contain more detailed information on the nature of the error.  An example error when a request is made without an API key:  ```json {   \"type\": \"authentication_error\",   \"status\": 401,   \"request_id\": \"8e3cc412-b49d-4957-9073-2c19d2c61804\",   \"errors\": [     {       \"code\": \"missing_authorization_material\",       \"message\": \"No authorization material provided in request\"     }   ] } ```  Note that the error:  - Contains the HTTP status (`401`) - References the type of error (`authentication_error`) - Includes a `request_id` that can be provided to incident.io support to help  debug questions with your API request - Provides a list of individual errors, which go into detail about why the error  occurred  The most common error will be a 422 Validation Error, which is returned when the request was rejected due to failing validations.  These errors look like this:  ```json {   \"type\": \"validation_error\",   \"status\": 422,   \"request_id\": \"631766c4-4afd-4803-997c-cd700928fa4b\",   \"errors\": [     {       \"code\": \"is_required\",       \"message\": \"A severity is required to open an incident\",       \"source\": {         \"field\": \"severity_id\"       }     }   ] } ```  This error is caused by not providing a severity identifier, which should be at the `severity_id` field of the request payload. Errors like these can be mapped to forms, should you be integrating with the API from a user-interface.  ## Compatibility  We won't make breaking changes to existing API services or endpoints, but will expect integrators to upgrade themselves to the latest API endpoints within 3 months of us deprecating the old service.  We will make changes that are considered backwards compatible, which include:  - Adding new API endpoints and services - Adding new properties to responses from existing API endpoints - Reordering properties returned from existing API endpoints - Adding optional request parameters to existing API endpoints - Altering the format or length of IDs - Adding new values to enums  It is important that clients are robust to these changes, to ensure reliable integrations.  As an example, if you are generating a client using an openapi-generator, ensure the generated client is configured to support unknown enum values, often configured via the `enumUnknownDefaultCase` parameter.  When breaking changes are unavoidable, we'll create a new service version on a separate path, and run them in parallel.  For example:  - https://api.incident.io/v1/incidents - https://api.incident.io/v2/incidents  For any questions, email support@incident.io. 
+
+The version of the OpenAPI document: 1.0.0
+
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for IncidentIoSdk::IncidentTypesV1Api
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'IncidentTypesV1Api' do
+  before do
+    # run before each test
+    @api_instance = IncidentIoSdk::IncidentTypesV1Api.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of IncidentTypesV1Api' do
+    it 'should create an instance of IncidentTypesV1Api' do
+      expect(@api_instance).to be_instance_of(IncidentIoSdk::IncidentTypesV1Api)
+    end
+  end
+
+  # unit tests for incident_types_v1_list
+  # List Incident Types V1
+  # List all incident types for an organisation.
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentTypesListResultV1]
+  describe 'incident_types_v1_list 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 incident_types_v1_show
+  # Show Incident Types V1
+  # Get a single incident type.
+  # @param id Unique identifier for this Incident Type
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentTypesShowResultV1]
+  describe 'incident_types_v1_show 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/incident_updates_v2_api_spec.rb

@@ -0,0 +1,49 @@
+=begin
+#incident.io
+
+#This is the API reference for incident.io.  It documents available API endpoints, provides examples of how to use it, and instructions around things like authentication and error handling.  The API is hosted at:  - https://api.incident.io/  And you will need to create an API key via your [incident.io dashboard](https://app.incident.io/settings/api-keys) to make requests.  # Making requests  Here are the key concepts required to make requests to the incident.io API.  ## Authentication  For all requests made to the incident.io API, you'll need an API key.  To create an API key, head to the incident dashboard and visit [API keys](https://app.incident.io/settings/api-keys). When you create the key, you'll be able to choose what actions it can take for your account: choose carefully, as those roles can only be set when you first create the key. We'll only show you the token once, so make sure you store it somewhere safe.  API keys are global to your incident.io account, and can be managed by anyone who has the right permissions. We display the user that created the API key, and the API key will remain valid if that user becomes deactivated.  Once you have the key, you should make requests to the API that set the `Authorization` request header using a \"Bearer\" authentication scheme:  ``` Authorization: Bearer <YOUR_API_KEY> ```  ## Rate Limits  The incident.io API enforces rate limits to ensure consistent performance for all users.  The default rate limit is 1200 requests/minute per API key. This limit applies to most endpoints across the API.  Some endpoints have lower rate limits, particularly those that interact with external third-party systems that impose their own limitations. These specific limits vary by endpoint, and we recommend relying on the rate-limit error responses to understand usage patterns and implement appropriate retry strategies.  When you exceed a rate limit, the API will respond with a `429 Too Many Requests` status code, along with a JSON response that includes information about the limit and when you can retry:  ```json {     \"type\": \"too_many_requests\",     \"status\": 429,     \"request_id\": \"b839a403-7704-41c1-bf6a-39a2d68caefa\",     \"rate_limit\": {         \"name\": \"api_key_name\",         \"limit\": 1200,         \"remaining\": 0,         \"retry_after\": \"Thu, 17 Apr 2025 11:17:18 UTC\"     },     \"errors\": [         {             \"code\": \"too_many_requests\",             \"message\": \"Too many requests hit the API too quickly. We recommend an exponential backoff of your requests.\"         }     ] } ```  The response includes: * The name of the API key (`name`) * The bucket limit (`limit`) * The number of requests remaining (`remaining`) * When you can retry requests (`retry_after`)  ## Errors  We use standard HTTP response codes to indicate the status or failure of API requests.  The API response body will be JSON, and contain more detailed information on the nature of the error.  An example error when a request is made without an API key:  ```json {   \"type\": \"authentication_error\",   \"status\": 401,   \"request_id\": \"8e3cc412-b49d-4957-9073-2c19d2c61804\",   \"errors\": [     {       \"code\": \"missing_authorization_material\",       \"message\": \"No authorization material provided in request\"     }   ] } ```  Note that the error:  - Contains the HTTP status (`401`) - References the type of error (`authentication_error`) - Includes a `request_id` that can be provided to incident.io support to help  debug questions with your API request - Provides a list of individual errors, which go into detail about why the error  occurred  The most common error will be a 422 Validation Error, which is returned when the request was rejected due to failing validations.  These errors look like this:  ```json {   \"type\": \"validation_error\",   \"status\": 422,   \"request_id\": \"631766c4-4afd-4803-997c-cd700928fa4b\",   \"errors\": [     {       \"code\": \"is_required\",       \"message\": \"A severity is required to open an incident\",       \"source\": {         \"field\": \"severity_id\"       }     }   ] } ```  This error is caused by not providing a severity identifier, which should be at the `severity_id` field of the request payload. Errors like these can be mapped to forms, should you be integrating with the API from a user-interface.  ## Compatibility  We won't make breaking changes to existing API services or endpoints, but will expect integrators to upgrade themselves to the latest API endpoints within 3 months of us deprecating the old service.  We will make changes that are considered backwards compatible, which include:  - Adding new API endpoints and services - Adding new properties to responses from existing API endpoints - Reordering properties returned from existing API endpoints - Adding optional request parameters to existing API endpoints - Altering the format or length of IDs - Adding new values to enums  It is important that clients are robust to these changes, to ensure reliable integrations.  As an example, if you are generating a client using an openapi-generator, ensure the generated client is configured to support unknown enum values, often configured via the `enumUnknownDefaultCase` parameter.  When breaking changes are unavoidable, we'll create a new service version on a separate path, and run them in parallel.  For example:  - https://api.incident.io/v1/incidents - https://api.incident.io/v2/incidents  For any questions, email support@incident.io. 
+
+The version of the OpenAPI document: 1.0.0
+
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for IncidentIoSdk::IncidentUpdatesV2Api
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'IncidentUpdatesV2Api' do
+  before do
+    # run before each test
+    @api_instance = IncidentIoSdk::IncidentUpdatesV2Api.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of IncidentUpdatesV2Api' do
+    it 'should create an instance of IncidentUpdatesV2Api' do
+      expect(@api_instance).to be_instance_of(IncidentIoSdk::IncidentUpdatesV2Api)
+    end
+  end
+
+  # unit tests for incident_updates_v2_list
+  # List Incident Updates V2
+  # List all incident updates for an organisation, or for a specific incident.
+  # @param [Hash] opts the optional parameters
+  # @option opts [String] :incident_id Incident whose updates you want to list
+  # @option opts [Integer] :page_size Integer number of records to return
+  # @option opts [String] :after An record&#39;s ID. This endpoint will return a list of records after this ID in relation to the API response order.
+  # @return [IncidentUpdatesListResultV2]
+  describe 'incident_updates_v2_list 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/incidents_v1_api_spec.rb

@@ -0,0 +1,73 @@
+=begin
+#incident.io
+
+#This is the API reference for incident.io.  It documents available API endpoints, provides examples of how to use it, and instructions around things like authentication and error handling.  The API is hosted at:  - https://api.incident.io/  And you will need to create an API key via your [incident.io dashboard](https://app.incident.io/settings/api-keys) to make requests.  # Making requests  Here are the key concepts required to make requests to the incident.io API.  ## Authentication  For all requests made to the incident.io API, you'll need an API key.  To create an API key, head to the incident dashboard and visit [API keys](https://app.incident.io/settings/api-keys). When you create the key, you'll be able to choose what actions it can take for your account: choose carefully, as those roles can only be set when you first create the key. We'll only show you the token once, so make sure you store it somewhere safe.  API keys are global to your incident.io account, and can be managed by anyone who has the right permissions. We display the user that created the API key, and the API key will remain valid if that user becomes deactivated.  Once you have the key, you should make requests to the API that set the `Authorization` request header using a \"Bearer\" authentication scheme:  ``` Authorization: Bearer <YOUR_API_KEY> ```  ## Rate Limits  The incident.io API enforces rate limits to ensure consistent performance for all users.  The default rate limit is 1200 requests/minute per API key. This limit applies to most endpoints across the API.  Some endpoints have lower rate limits, particularly those that interact with external third-party systems that impose their own limitations. These specific limits vary by endpoint, and we recommend relying on the rate-limit error responses to understand usage patterns and implement appropriate retry strategies.  When you exceed a rate limit, the API will respond with a `429 Too Many Requests` status code, along with a JSON response that includes information about the limit and when you can retry:  ```json {     \"type\": \"too_many_requests\",     \"status\": 429,     \"request_id\": \"b839a403-7704-41c1-bf6a-39a2d68caefa\",     \"rate_limit\": {         \"name\": \"api_key_name\",         \"limit\": 1200,         \"remaining\": 0,         \"retry_after\": \"Thu, 17 Apr 2025 11:17:18 UTC\"     },     \"errors\": [         {             \"code\": \"too_many_requests\",             \"message\": \"Too many requests hit the API too quickly. We recommend an exponential backoff of your requests.\"         }     ] } ```  The response includes: * The name of the API key (`name`) * The bucket limit (`limit`) * The number of requests remaining (`remaining`) * When you can retry requests (`retry_after`)  ## Errors  We use standard HTTP response codes to indicate the status or failure of API requests.  The API response body will be JSON, and contain more detailed information on the nature of the error.  An example error when a request is made without an API key:  ```json {   \"type\": \"authentication_error\",   \"status\": 401,   \"request_id\": \"8e3cc412-b49d-4957-9073-2c19d2c61804\",   \"errors\": [     {       \"code\": \"missing_authorization_material\",       \"message\": \"No authorization material provided in request\"     }   ] } ```  Note that the error:  - Contains the HTTP status (`401`) - References the type of error (`authentication_error`) - Includes a `request_id` that can be provided to incident.io support to help  debug questions with your API request - Provides a list of individual errors, which go into detail about why the error  occurred  The most common error will be a 422 Validation Error, which is returned when the request was rejected due to failing validations.  These errors look like this:  ```json {   \"type\": \"validation_error\",   \"status\": 422,   \"request_id\": \"631766c4-4afd-4803-997c-cd700928fa4b\",   \"errors\": [     {       \"code\": \"is_required\",       \"message\": \"A severity is required to open an incident\",       \"source\": {         \"field\": \"severity_id\"       }     }   ] } ```  This error is caused by not providing a severity identifier, which should be at the `severity_id` field of the request payload. Errors like these can be mapped to forms, should you be integrating with the API from a user-interface.  ## Compatibility  We won't make breaking changes to existing API services or endpoints, but will expect integrators to upgrade themselves to the latest API endpoints within 3 months of us deprecating the old service.  We will make changes that are considered backwards compatible, which include:  - Adding new API endpoints and services - Adding new properties to responses from existing API endpoints - Reordering properties returned from existing API endpoints - Adding optional request parameters to existing API endpoints - Altering the format or length of IDs - Adding new values to enums  It is important that clients are robust to these changes, to ensure reliable integrations.  As an example, if you are generating a client using an openapi-generator, ensure the generated client is configured to support unknown enum values, often configured via the `enumUnknownDefaultCase` parameter.  When breaking changes are unavoidable, we'll create a new service version on a separate path, and run them in parallel.  For example:  - https://api.incident.io/v1/incidents - https://api.incident.io/v2/incidents  For any questions, email support@incident.io. 
+
+The version of the OpenAPI document: 1.0.0
+
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for IncidentIoSdk::IncidentsV1Api
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'IncidentsV1Api' do
+  before do
+    # run before each test
+    @api_instance = IncidentIoSdk::IncidentsV1Api.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of IncidentsV1Api' do
+    it 'should create an instance of IncidentsV1Api' do
+      expect(@api_instance).to be_instance_of(IncidentIoSdk::IncidentsV1Api)
+    end
+  end
+
+  # unit tests for incidents_v1_create
+  # Create Incidents V1
+  # Create a new incident.
+  # @param incidents_create_payload_v1 
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentsCreateResultV1]
+  describe 'incidents_v1_create 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 incidents_v1_list
+  # List Incidents V1
+  # List all incidents for an organisation.
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :page_size Integer number of records to return
+  # @option opts [String] :after An record&#39;s ID. This endpoint will return a list of records after this ID in relation to the API response order.
+  # @option opts [Array<String>] :status Filter for incidents in these statuses
+  # @return [IncidentsListResultV1]
+  describe 'incidents_v1_list 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 incidents_v1_show
+  # Show Incidents V1
+  # Get a single incident.
+  # @param id Unique identifier for the incident
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentsShowResultV1]
+  describe 'incidents_v1_show 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/incidents_v2_api_spec.rb

@@ -0,0 +1,94 @@
+=begin
+#incident.io
+
+#This is the API reference for incident.io.  It documents available API endpoints, provides examples of how to use it, and instructions around things like authentication and error handling.  The API is hosted at:  - https://api.incident.io/  And you will need to create an API key via your [incident.io dashboard](https://app.incident.io/settings/api-keys) to make requests.  # Making requests  Here are the key concepts required to make requests to the incident.io API.  ## Authentication  For all requests made to the incident.io API, you'll need an API key.  To create an API key, head to the incident dashboard and visit [API keys](https://app.incident.io/settings/api-keys). When you create the key, you'll be able to choose what actions it can take for your account: choose carefully, as those roles can only be set when you first create the key. We'll only show you the token once, so make sure you store it somewhere safe.  API keys are global to your incident.io account, and can be managed by anyone who has the right permissions. We display the user that created the API key, and the API key will remain valid if that user becomes deactivated.  Once you have the key, you should make requests to the API that set the `Authorization` request header using a \"Bearer\" authentication scheme:  ``` Authorization: Bearer <YOUR_API_KEY> ```  ## Rate Limits  The incident.io API enforces rate limits to ensure consistent performance for all users.  The default rate limit is 1200 requests/minute per API key. This limit applies to most endpoints across the API.  Some endpoints have lower rate limits, particularly those that interact with external third-party systems that impose their own limitations. These specific limits vary by endpoint, and we recommend relying on the rate-limit error responses to understand usage patterns and implement appropriate retry strategies.  When you exceed a rate limit, the API will respond with a `429 Too Many Requests` status code, along with a JSON response that includes information about the limit and when you can retry:  ```json {     \"type\": \"too_many_requests\",     \"status\": 429,     \"request_id\": \"b839a403-7704-41c1-bf6a-39a2d68caefa\",     \"rate_limit\": {         \"name\": \"api_key_name\",         \"limit\": 1200,         \"remaining\": 0,         \"retry_after\": \"Thu, 17 Apr 2025 11:17:18 UTC\"     },     \"errors\": [         {             \"code\": \"too_many_requests\",             \"message\": \"Too many requests hit the API too quickly. We recommend an exponential backoff of your requests.\"         }     ] } ```  The response includes: * The name of the API key (`name`) * The bucket limit (`limit`) * The number of requests remaining (`remaining`) * When you can retry requests (`retry_after`)  ## Errors  We use standard HTTP response codes to indicate the status or failure of API requests.  The API response body will be JSON, and contain more detailed information on the nature of the error.  An example error when a request is made without an API key:  ```json {   \"type\": \"authentication_error\",   \"status\": 401,   \"request_id\": \"8e3cc412-b49d-4957-9073-2c19d2c61804\",   \"errors\": [     {       \"code\": \"missing_authorization_material\",       \"message\": \"No authorization material provided in request\"     }   ] } ```  Note that the error:  - Contains the HTTP status (`401`) - References the type of error (`authentication_error`) - Includes a `request_id` that can be provided to incident.io support to help  debug questions with your API request - Provides a list of individual errors, which go into detail about why the error  occurred  The most common error will be a 422 Validation Error, which is returned when the request was rejected due to failing validations.  These errors look like this:  ```json {   \"type\": \"validation_error\",   \"status\": 422,   \"request_id\": \"631766c4-4afd-4803-997c-cd700928fa4b\",   \"errors\": [     {       \"code\": \"is_required\",       \"message\": \"A severity is required to open an incident\",       \"source\": {         \"field\": \"severity_id\"       }     }   ] } ```  This error is caused by not providing a severity identifier, which should be at the `severity_id` field of the request payload. Errors like these can be mapped to forms, should you be integrating with the API from a user-interface.  ## Compatibility  We won't make breaking changes to existing API services or endpoints, but will expect integrators to upgrade themselves to the latest API endpoints within 3 months of us deprecating the old service.  We will make changes that are considered backwards compatible, which include:  - Adding new API endpoints and services - Adding new properties to responses from existing API endpoints - Reordering properties returned from existing API endpoints - Adding optional request parameters to existing API endpoints - Altering the format or length of IDs - Adding new values to enums  It is important that clients are robust to these changes, to ensure reliable integrations.  As an example, if you are generating a client using an openapi-generator, ensure the generated client is configured to support unknown enum values, often configured via the `enumUnknownDefaultCase` parameter.  When breaking changes are unavoidable, we'll create a new service version on a separate path, and run them in parallel.  For example:  - https://api.incident.io/v1/incidents - https://api.incident.io/v2/incidents  For any questions, email support@incident.io. 
+
+The version of the OpenAPI document: 1.0.0
+
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for IncidentIoSdk::IncidentsV2Api
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'IncidentsV2Api' do
+  before do
+    # run before each test
+    @api_instance = IncidentIoSdk::IncidentsV2Api.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of IncidentsV2Api' do
+    it 'should create an instance of IncidentsV2Api' do
+      expect(@api_instance).to be_instance_of(IncidentIoSdk::IncidentsV2Api)
+    end
+  end
+
+  # unit tests for incidents_v2_create
+  # Create Incidents V2
+  # Create a new incident.  Note that if the incident mode is set to \&quot;retrospective\&quot; then the new incident will not be announced in Slack. 
+  # @param incidents_create_payload_v2 
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentsCreateResultV2]
+  describe 'incidents_v2_create 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 incidents_v2_edit
+  # Edit Incidents V2
+  # Edit an existing incident.  This endpoint allows you to edit the properties of an existing incident: e.g. set the severity or update custom fields.  When using this endpoint, only fields that are provided will be edited (omitted fields will be ignored). 
+  # @param id The unique identifier of the incident that you want to edit
+  # @param incidents_edit_payload_v2 
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentsEditResultV2]
+  describe 'incidents_v2_edit 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 incidents_v2_list
+  # List Incidents V2
+  # List all incidents for an organisation.  This endpoint supports a number of filters, which can help find incidents matching certain criteria.  Filters are provided as query parameters, but due to the dynamic nature of what you can query by (different accounts have different custom fields, statuses, etc) they are more complex than most.  The maximum page size that can be requested is 250.  To help, here are some exemplar curl requests with a human description of what they search for.  Note that: - Filters may be used together, and the result will be incidents that match all filters. - IDs are normally in UUID format, but have been replaced with shorter strings to improve readability. - All query parameters must be URI encoded.  ### By status  With status of id&#x3D;ABC, find all incidents that are set to that status:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;status[one_of]&#x3D;ABC&#39;  Or all incidents that are not set to status with id&#x3D;ABC:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;status[not_in]&#x3D;ABC&#39;  ### By created_at or updated_at  Find all incidents that follow specified date parameters for created_at and updated_at fields. Possible values are \&quot;gte\&quot; (greater than or equal to) and \&quot;lte\&quot; (less than or equal to). The following example finds all incidents created before or on 2021-01-02T00:00:00Z:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;created_at[lte]&#x3D;2021-01-02&#39;  ### By status category  Find all incidents that are in a status category. Possible values are \&quot;triage\&quot;, \&quot;declined\&quot;, \&quot;merged\&quot;, \&quot;canceled\&quot;, \&quot;live\&quot;, \&quot;learning\&quot; and \&quot;closed\&quot;:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;status_category[one_of]&#x3D;live&#39;  Or all incidents that are not in a status category:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;status_category[not_in]&#x3D;live&#39;   ### By severity  With severity of id&#x3D;ABC, find all incidents that are set to that severity:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;severity[one_of]&#x3D;ABC&#39;  Or all incidents where severity rank is greater-than-or-equal-to the rank of severity id&#x3D;ABC:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;severity[gte]&#x3D;ABC&#39;  Or all incidents where severity rank is less-than-or-equal-to the rank of severity id&#x3D;ABC:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;severity[lte]&#x3D;ABC&#39;  ### By incident type  With incident type of id&#x3D;ABC, find all incidents that are of that type:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;incident_type[one_of]&#x3D;ABC&#39;  Or all incidents not of that type:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;incident_type[not_in]&#x3D;ABC&#39;  ### By incident mode  By default, we return standard and retrospective incidents. This means that test and tutorial incidents are filtered out. To override this behaviour, you can use the mode filter to specify which modes you want to get.  To find incidents of all modes:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;mode[one_of]&#x3D;standard&amp;mode[one_of]&#x3D;retrospective&amp;mode[one_of]&#x3D;test&amp;mode[one_of]&#x3D;tutorial&#39;  To find just test incidents:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;mode[one_of]&#x3D;test&#39;   ### By incident role  Roles and custom fields have another nested layer in the query parameter, to account for operations against any of the roles or custom fields created in the account.  With incident role id&#x3D;ABC, find all incidents where that role is unset:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;incident_role[ABC][is_blank]&#x3D;true&#39;  Or where the role has been set:    curl --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;incident_role[ABC][is_blank]&#x3D;false&#39;  ### By option custom fields  With an option custom field id&#x3D;ABC, all incidents that have field ABC set to the custom field option of id&#x3D;XYZ:    curl \\    --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;custom_field[ABC][one_of]&#x3D;XYZ&#39;  Or all incidents that do not have custom field id&#x3D;ABC set to option id&#x3D;XYZ:    curl \\    --get &#39;https://api.incident.io/v2/incidents&#39; \\    --data &#39;custom_field[ABC][not_in]&#x3D;XYZ&#39; 
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :page_size number of records to return
+  # @option opts [String] :after An incident&#39;s ID. This endpoint will return a list of incidents after this ID in relation to the API response order.
+  # @option opts [Hash<String, Array<String>>] :status Filter on incident status. The accepted operators are &#39;one_of&#39;, or &#39;not_in&#39;.
+  # @option opts [Hash<String, Array<String>>] :status_category Filter on the category of the incidents status. The accepted operators are &#39;one_of&#39;, or &#39;not_in&#39;.
+  # @option opts [Hash<String, Array<String>>] :created_at Filter on incident created at timestamp. The accepted operators are &#39;gte&#39;, &#39;lte&#39; and &#39;date_range&#39;.
+  # @option opts [Hash<String, Array<String>>] :updated_at Filter on incident updated at timestamp. The accepted operators are &#39;gte&#39;, &#39;lte&#39; and &#39;date_range&#39;.
+  # @option opts [Hash<String, Array<String>>] :severity Filter on incident severity. The accepted operators are &#39;one_of&#39;, &#39;not_in&#39;, &#39;gte&#39;, &#39;lte&#39;.
+  # @option opts [Hash<String, Array<String>>] :incident_type Filter on incident type. The accepted operators are &#39;one_of, or &#39;not_in&#39;.
+  # @option opts [Hash<String, Hash<String, Array<String>>>] :incident_role Filter on an incident role. Role ID should be sent, followed by the operator and values. The accepted operators are &#39;one_of&#39;, &#39;is_blank&#39;.
+  # @option opts [Hash<String, Hash<String, Array<String>>>] :custom_field Filter on an incident custom field. Custom field ID should be sent, followed by the operator and values. Accepted operator will depend on the custom field type.
+  # @option opts [Hash<String, Array<String>>] :mode Filter on incident mode. The accepted operator is &#39;one_of&#39;.  If this is not provided, this value defaults to &#x60;{\&quot;one_of\&quot;: [\&quot;standard\&quot;, \&quot;retrospective\&quot;] }&#x60;, meaning that test and tutorial incidents are not included.
+  # @return [IncidentsListResultV2]
+  describe 'incidents_v2_list 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 incidents_v2_show
+  # Show Incidents V2
+  # Get a single incident.  The ID supplied can be either the incident&#39;s full ID, or the numeric part of its reference. For example, to get INC-123, you could use either its full ID or:    curl \\    --get &#39;https://api.incident.io/v2/incidents/123 
+  # @param id Unique identifier for the incident
+  # @param [Hash] opts the optional parameters
+  # @return [IncidentsShowResultV2]
+  describe 'incidents_v2_show 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/schedules_v2_api_spec.rb

@@ -0,0 +1,123 @@
+=begin
+#incident.io
+
+#This is the API reference for incident.io.  It documents available API endpoints, provides examples of how to use it, and instructions around things like authentication and error handling.  The API is hosted at:  - https://api.incident.io/  And you will need to create an API key via your [incident.io dashboard](https://app.incident.io/settings/api-keys) to make requests.  # Making requests  Here are the key concepts required to make requests to the incident.io API.  ## Authentication  For all requests made to the incident.io API, you'll need an API key.  To create an API key, head to the incident dashboard and visit [API keys](https://app.incident.io/settings/api-keys). When you create the key, you'll be able to choose what actions it can take for your account: choose carefully, as those roles can only be set when you first create the key. We'll only show you the token once, so make sure you store it somewhere safe.  API keys are global to your incident.io account, and can be managed by anyone who has the right permissions. We display the user that created the API key, and the API key will remain valid if that user becomes deactivated.  Once you have the key, you should make requests to the API that set the `Authorization` request header using a \"Bearer\" authentication scheme:  ``` Authorization: Bearer <YOUR_API_KEY> ```  ## Rate Limits  The incident.io API enforces rate limits to ensure consistent performance for all users.  The default rate limit is 1200 requests/minute per API key. This limit applies to most endpoints across the API.  Some endpoints have lower rate limits, particularly those that interact with external third-party systems that impose their own limitations. These specific limits vary by endpoint, and we recommend relying on the rate-limit error responses to understand usage patterns and implement appropriate retry strategies.  When you exceed a rate limit, the API will respond with a `429 Too Many Requests` status code, along with a JSON response that includes information about the limit and when you can retry:  ```json {     \"type\": \"too_many_requests\",     \"status\": 429,     \"request_id\": \"b839a403-7704-41c1-bf6a-39a2d68caefa\",     \"rate_limit\": {         \"name\": \"api_key_name\",         \"limit\": 1200,         \"remaining\": 0,         \"retry_after\": \"Thu, 17 Apr 2025 11:17:18 UTC\"     },     \"errors\": [         {             \"code\": \"too_many_requests\",             \"message\": \"Too many requests hit the API too quickly. We recommend an exponential backoff of your requests.\"         }     ] } ```  The response includes: * The name of the API key (`name`) * The bucket limit (`limit`) * The number of requests remaining (`remaining`) * When you can retry requests (`retry_after`)  ## Errors  We use standard HTTP response codes to indicate the status or failure of API requests.  The API response body will be JSON, and contain more detailed information on the nature of the error.  An example error when a request is made without an API key:  ```json {   \"type\": \"authentication_error\",   \"status\": 401,   \"request_id\": \"8e3cc412-b49d-4957-9073-2c19d2c61804\",   \"errors\": [     {       \"code\": \"missing_authorization_material\",       \"message\": \"No authorization material provided in request\"     }   ] } ```  Note that the error:  - Contains the HTTP status (`401`) - References the type of error (`authentication_error`) - Includes a `request_id` that can be provided to incident.io support to help  debug questions with your API request - Provides a list of individual errors, which go into detail about why the error  occurred  The most common error will be a 422 Validation Error, which is returned when the request was rejected due to failing validations.  These errors look like this:  ```json {   \"type\": \"validation_error\",   \"status\": 422,   \"request_id\": \"631766c4-4afd-4803-997c-cd700928fa4b\",   \"errors\": [     {       \"code\": \"is_required\",       \"message\": \"A severity is required to open an incident\",       \"source\": {         \"field\": \"severity_id\"       }     }   ] } ```  This error is caused by not providing a severity identifier, which should be at the `severity_id` field of the request payload. Errors like these can be mapped to forms, should you be integrating with the API from a user-interface.  ## Compatibility  We won't make breaking changes to existing API services or endpoints, but will expect integrators to upgrade themselves to the latest API endpoints within 3 months of us deprecating the old service.  We will make changes that are considered backwards compatible, which include:  - Adding new API endpoints and services - Adding new properties to responses from existing API endpoints - Reordering properties returned from existing API endpoints - Adding optional request parameters to existing API endpoints - Altering the format or length of IDs - Adding new values to enums  It is important that clients are robust to these changes, to ensure reliable integrations.  As an example, if you are generating a client using an openapi-generator, ensure the generated client is configured to support unknown enum values, often configured via the `enumUnknownDefaultCase` parameter.  When breaking changes are unavoidable, we'll create a new service version on a separate path, and run them in parallel.  For example:  - https://api.incident.io/v1/incidents - https://api.incident.io/v2/incidents  For any questions, email support@incident.io. 
+
+The version of the OpenAPI document: 1.0.0
+
+Generated by: https://openapi-generator.tech
+Generator version: 7.12.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for IncidentIoSdk::SchedulesV2Api
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'SchedulesV2Api' do
+  before do
+    # run before each test
+    @api_instance = IncidentIoSdk::SchedulesV2Api.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of SchedulesV2Api' do
+    it 'should create an instance of SchedulesV2Api' do
+      expect(@api_instance).to be_instance_of(IncidentIoSdk::SchedulesV2Api)
+    end
+  end
+
+  # unit tests for schedules_v2_create
+  # Create Schedules V2
+  # Create a new schedule.
+  # @param schedules_create_payload_v2 
+  # @param [Hash] opts the optional parameters
+  # @return [SchedulesCreateResultV2]
+  describe 'schedules_v2_create 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 schedules_v2_create_override
+  # CreateOverride Schedules V2
+  # Create a new schedule override.
+  # @param schedules_create_override_payload_v2 
+  # @param [Hash] opts the optional parameters
+  # @return [SchedulesCreateOverrideResultV2]
+  describe 'schedules_v2_create_override 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 schedules_v2_destroy
+  # Destroy Schedules V2
+  # Archives a single schedule.
+  # @param id Unique internal ID of the schedule
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'schedules_v2_destroy 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 schedules_v2_list
+  # List Schedules V2
+  # List configured schedules.
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :page_size number of records to return
+  # @option opts [String] :after A schedule&#39;s ID. This endpoint will return a list of schedules after this ID in relation to the API response order.
+  # @return [SchedulesListResultV2]
+  describe 'schedules_v2_list 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 schedules_v2_list_schedule_entries
+  # ListScheduleEntries Schedules V2
+  # Get a list of schedule entries. The endpoint will return all entries that overlap with the given window, if one is provided.
+  # @param schedule_id The ID of the schedule to get entries for.
+  # @param [Hash] opts the optional parameters
+  # @option opts [Time] :entry_window_start The start of the window to get entries for.
+  # @option opts [Time] :entry_window_end The end of the window to get entries for.
+  # @return [SchedulesListScheduleEntriesResultV2]
+  describe 'schedules_v2_list_schedule_entries 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 schedules_v2_show
+  # Show Schedules V2
+  # Get a single schedule.
+  # @param id Unique internal ID of the schedule
+  # @param [Hash] opts the optional parameters
+  # @return [SchedulesShowResultV2]
+  describe 'schedules_v2_show 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 schedules_v2_update
+  # Update Schedules V2
+  # Update a schedule.
+  # @param id The schedule ID to update.
+  # @param schedules_update_payload_v2 
+  # @param [Hash] opts the optional parameters
+  # @return [SchedulesUpdateResultV2]
+  describe 'schedules_v2_update test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+end