incident_io_api 2.33.0 → 2.34.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 845b36fa19dcf1a1650ccd79b5da5a234ff87e56ead4c93cc9f656f07a10e189
-  data.tar.gz: e74685531971721e27fccd8680890ffab380a30b143433dd41fbf600a81450a4
+  metadata.gz: 9dd7ecb3b35269475cee94bd36d4e29115b35de1c84241b1f2a9bd5148f62be7
+  data.tar.gz: e8f88e4f40553ee8165828caac3c99d8389f9e47bee801c5dd15d99f701c1bce
 SHA512:
-  metadata.gz: cd4b1edce8e3735ab6c7cfd750db7321d23d957886656e85716d9bea3dedefa69fe10967c4971be578a8064ac324e49fc13a6699c76cb8b3bd40135d3552ddb7
-  data.tar.gz: 34bbec0f6f701ca96c0b670ed3b2666dc454118427e8bcdd907cfd29b7045bf1eba1afd741370137fedf2c7de5da734451df7c81ced606a7785ed0247a9be317
+  metadata.gz: 111916e073829c1afc366fbc07e726c1f88ee46c5163657354ceb606bc2592be3f7f5651438851bffe0de5b01500063eb7781b535eddab7b4149d864cf4b2ff3
+  data.tar.gz: 779c9106fe2f0b1e5cf539cad1c28462fcd994f817775f03221e51b99d16c83088e3be3dc055f060d7b5d169be183771e3bb808ec031992ba32d3c57425e5f4d

data/lib/incident_io/api/escalations_v2_api.rb

@@ -519,7 +519,7 @@ module IncidentIo
     end
 
     # ReassignEscalation Escalations V2
-    # Reassign an escalation to a different escalation path or set of users.  Use this when a page reached the wrong people. Reassigning creates a new escalation aimed at the targets you give, linked back to the original, and carries over the original's title, description, priority, incident and alert so the page stays attached to the same alert and acknowledgements keep grouping under it.  You must provide either an escalation_path_id OR user_ids, but not both. Both name incident.io escalation paths and users, so an escalation cannot be reassigned to an external escalator such as PagerDuty or Opsgenie.  By default the original escalation is resolved, so the first targets stop being paged. Pass resolve_original=false to leave it running alongside the new one. Resolving the original additionally needs the \"escalations.respond\" permission, since it stops a page someone else may be responding to.  An escalation can only be reassigned once: calling this again for the same escalation is rejected. Retrying a request whose response you never saw is safe in the sense that matters — a reassignment that already happened is never repeated, so nobody is paged twice — but the retry is rejected rather than returning the escalation the first call created, so keep the ID from the original response.  To use this API, you will need an API key with the \"Create and manage escalations\" permission. The reassignment is attributed to the key; to attribute it to one of your users instead, set the X-Incident-User header, which needs the \"api_keys.act_on_behalf_of_users\" scope.  If your API key's permissions are scoped to teams, the escalation you're reassigning must be owned by one of those teams, and you can only reassign via an escalation path one of them owns. Reassigning directly to user_ids needs the permission at the account level, because an escalation aimed at a person has no owning team.
+    # Reassign an escalation to a different escalation path or set of users.  Use this when a page reached the wrong people. Reassigning creates a new escalation aimed at the targets you give, linked back to the original, and carries over the original's title, description, priority, incident and alert so the page stays attached to the same alert and acknowledgements keep grouping under it.  You must provide either an escalation_path_id OR user_ids, but not both. Both name incident.io escalation paths and users, so an escalation cannot be reassigned to an external escalator such as PagerDuty or Opsgenie.  By default the original escalation is resolved, so the first targets stop being paged. Pass resolve_original=false to leave it running alongside the new one. Resolving the original additionally needs the \"escalations.respond\" permission, since it stops a page someone else may be responding to.  An escalation can only be reassigned once: calling this again for the same escalation is rejected. Retrying a request whose response you never saw is safe in the sense that matters — a reassignment that already happened is never repeated, so nobody is paged twice — but the retry is rejected rather than returning the escalation the first call created, so keep the ID from the original response.  To use this API, you will need an API key with the \"Create and manage escalations\" permission. The reassignment is attributed to the key; to attribute it to one of your users instead, set the X-Incident-User header, which needs the \"api_keys.act_on_behalf_of_users\" scope and no team permissions on the key.  If your API key's permissions are scoped to teams, the escalation you're reassigning must be owned by one of those teams, and you can only reassign via an escalation path one of them owns. Reassigning directly to user_ids needs the permission at the account level, because an escalation aimed at a person has no owning team.
     # @param escalation_id [String] The ID of the escalation to reassign
     # @param escalations_reassign_escalation_payload_v2 [EscalationsReassignEscalationPayloadV2] 
     # @param [Hash] opts the optional parameters
@@ -530,7 +530,7 @@ module IncidentIo
     end
 
     # ReassignEscalation Escalations V2
-    # Reassign an escalation to a different escalation path or set of users.  Use this when a page reached the wrong people. Reassigning creates a new escalation aimed at the targets you give, linked back to the original, and carries over the original's title, description, priority, incident and alert so the page stays attached to the same alert and acknowledgements keep grouping under it.  You must provide either an escalation_path_id OR user_ids, but not both. Both name incident.io escalation paths and users, so an escalation cannot be reassigned to an external escalator such as PagerDuty or Opsgenie.  By default the original escalation is resolved, so the first targets stop being paged. Pass resolve_original=false to leave it running alongside the new one. Resolving the original additionally needs the \"escalations.respond\" permission, since it stops a page someone else may be responding to.  An escalation can only be reassigned once: calling this again for the same escalation is rejected. Retrying a request whose response you never saw is safe in the sense that matters — a reassignment that already happened is never repeated, so nobody is paged twice — but the retry is rejected rather than returning the escalation the first call created, so keep the ID from the original response.  To use this API, you will need an API key with the \"Create and manage escalations\" permission. The reassignment is attributed to the key; to attribute it to one of your users instead, set the X-Incident-User header, which needs the \"api_keys.act_on_behalf_of_users\" scope.  If your API key's permissions are scoped to teams, the escalation you're reassigning must be owned by one of those teams, and you can only reassign via an escalation path one of them owns. Reassigning directly to user_ids needs the permission at the account level, because an escalation aimed at a person has no owning team.
+    # Reassign an escalation to a different escalation path or set of users.  Use this when a page reached the wrong people. Reassigning creates a new escalation aimed at the targets you give, linked back to the original, and carries over the original's title, description, priority, incident and alert so the page stays attached to the same alert and acknowledgements keep grouping under it.  You must provide either an escalation_path_id OR user_ids, but not both. Both name incident.io escalation paths and users, so an escalation cannot be reassigned to an external escalator such as PagerDuty or Opsgenie.  By default the original escalation is resolved, so the first targets stop being paged. Pass resolve_original=false to leave it running alongside the new one. Resolving the original additionally needs the \"escalations.respond\" permission, since it stops a page someone else may be responding to.  An escalation can only be reassigned once: calling this again for the same escalation is rejected. Retrying a request whose response you never saw is safe in the sense that matters — a reassignment that already happened is never repeated, so nobody is paged twice — but the retry is rejected rather than returning the escalation the first call created, so keep the ID from the original response.  To use this API, you will need an API key with the \"Create and manage escalations\" permission. The reassignment is attributed to the key; to attribute it to one of your users instead, set the X-Incident-User header, which needs the \"api_keys.act_on_behalf_of_users\" scope and no team permissions on the key.  If your API key's permissions are scoped to teams, the escalation you're reassigning must be owned by one of those teams, and you can only reassign via an escalation path one of them owns. Reassigning directly to user_ids needs the permission at the account level, because an escalation aimed at a person has no owning team.
     # @param escalation_id [String] The ID of the escalation to reassign
     # @param escalations_reassign_escalation_payload_v2 [EscalationsReassignEscalationPayloadV2] 
     # @param [Hash] opts the optional parameters

data/lib/incident_io/version.rb

@@ -4,5 +4,5 @@ module IncidentIo
   # The release workflow sets this before building, so it tracks whatever we
   # last published. Listed in .openapi-generator-ignore so regeneration can't
   # reset it.
-  VERSION = "2.33.0"
+  VERSION = "2.34.0"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: incident_io_api
 version: !ruby/object:Gem::Version
-  version: 2.33.0
+  version: 2.34.0
 platform: ruby
 authors:
 - incident.io
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2026-10-27 00:00:00.000000000 Z
+date: 2026-10-28 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: faraday