API CHANGE TRACKER / PagerDuty
PagerDuty breaking change: PUT /v3/schedules/{id}/custom_shifts/{custom_shift_id}
the request property `custom_shift/end_time` became required
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
custom_shift/end_time- Rule ID
request.now_required- Classifier version
2026-10-15.2- Direction
- request
- Finding ID
chg_edcd464db7bf7161e7769aae7d3e4390da3ddecdf6ab1369152d1d1ee32eeab3
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