API CHANGE TRACKER / PagerDuty
PagerDuty breaking change: PUT /v3/schedules/{id}/custom_shifts/{custom_shift_id}
Validated schema comparison changed the request accepted instance set.
Specification capture: . Published evidence last updated . This is captured contract evidence, not an observed outage or a result from scanning your code.
Which field and classification rule changed?
- Changed field
Operation-level change- Rule ID
schema.request_acceptance_narrowed- Classifier version
2026-10-15.2- Direction
- request
- Finding ID
chg_ce912314a98bf0cba5e1c963090474ca3bdf05a5b5dbbd9e9e435d2255d33b36
What is the recorded before and after evidence?
Previous specification SHA-256: 6c19f1f4b622e7d098e0a5a5f5ce04afdc0a21a5b9c1cb7b1649a594e88f2345
Revised specification SHA-256: 46bd6195063f262aef3b13de96e7c206d5c6f3e6aa79154c5655cce436b584db
Publisher version: 2.0.0 to 2.0.0.
...
end_time: 2025-03-15T18:00:00Z
start_time: 2025-03-15T10:00:00Z
+ type: custom_shift
schema:
properties:
custom_shift:
description: |
+ The request replaces the full custom shift. Send every required
+ field, even the fields that do not change.
+
If the shift has already started,
only `end_time` can be modified.
...
format: date-time
type: string
+ type:
+ enum:
+ - custom_shift
+ type: string
+ required:
+ - type
+ - start_time
+ - end_time
+ - assignments
type: object
required:
...Inspect the complete release · Public source findings · Publisher specification source
How do I check whether this affects my code?
Confirm the affected operation and field in the repository commit you authorize. Inspect supported SDK and HTTP call-site matches, review dynamic or unmatched patterns, and choose the intended application behavior before approving a proposal. Schema validation, type checks, configured runtime checks, and your CI provide different evidence.
Check an authorized repository · Review coverage · Inspect classification rules