---
title: "Create an event"
method: POST
path: "/v3/schedules/{id}/rotations/{rotation_id}/events"
tags: ["Schedules_v3"]
---

# Create an event

`POST /v3/schedules/{id}/rotations/{rotation_id}/events`

<!-- theme: info -->

> **Important note:** Shift-based schedules use the V3 API and are not compatible with V2 automations. **To create automations for Shift-Based Schedules, you need to:**
>
> 1. **Update your automations** to use the V3 API for all new shift-based schedules
> 2. **Keep the V2 endpoint** for your existing schedules
>
> An upgrade tool for existing schedules is coming soon; your legacy schedules will keep working in the meantime. [Learn more](https://support.pagerduty.com/main/docs/shift-based-schedules-api-upgrade-examples).

Create a new event that defines when and how users are on-call within
a rotation.

**Constraints:**
- Maximum 5 events per rotation
- Events within a rotation cannot overlap
- `effective_since` must be in the future (past values are clamped to now)
- All users referenced in `assignment_strategy.members` must exist and
  belong to the account

## Path parameters

- `id` string, required
- `rotation_id` string, required

## Request body

- CreateEventRequest
  - `event` object, required
    - `name` string, required
    - `start_time` ZonedDateTime, required — A time-of-day value with an explicit time zone. Used for event `start_time` and `end_time` to define the recurring window of coverage (e.g., 9 AM–5 PM every Monday in New York).
      - `date_time` string, date-time, required — The date and time
      - `time_zone` string, required — IANA timezone identifier
    - `end_time` ZonedDateTime, required — A time-of-day value with an explicit time zone. Used for event `start_time` and `end_time` to define the recurring window of coverage (e.g., 9 AM–5 PM every Monday in New York).
      - `date_time` string, date-time, required — The date and time
      - `time_zone` string, required — IANA timezone identifier
    - `effective_since` string, date-time, required — When this event starts producing shifts. Values in the past are clamped to the current time.
    - `effective_until` string, date-time, nullable — When this event stops producing shifts. Omit or null for indefinite.
    - `recurrence` string[], required — RFC 5545 recurrence rules. Must be an array containing exactly one RRULE, zero or more EXDATE, and zero or more RDATE. **UI editor constraints:** The shift-based schedule editor can only load an event when the RRULE satisfies all of the following: 1. A `FREQ` parameter is present. 2. `FREQ` is one of `WEEKLY`, `DAILY`, `MONTHLY`, or `HOURLY`. 3. All `BYDAY` values are standard two-letter day codes (`MO`, `TU`, `WE`, `TH`, `FR`, `SA`, `SU`). Events that violate any condition display a "can't be edited in the UI" modal and must be managed via the API.
    - `assignment_strategy` EventAssignmentStrategy, required — Defines how users are assigned on-call within an event's time window. - `rotating_member_assignment_strategy`: users rotate in sequence. `shifts_per_member` controls how many consecutive shift periods each member covers before rotating. - `every_member_assignment_strategy`: all listed members are on-call simultaneously for every occurrence.
      - `type` 'rotating_member_assignment_strategy' | 'every_member_assignment_strategy', required
      - `shifts_per_member` integer — Required for `rotating_member_assignment_strategy`. Number of consecutive shift occurrences each member covers before the next member takes over. **UI editor constraint:** When `recurrence` uses `FREQ=WEEKLY`, `shifts_per_member` must be evenly divisible by the number of days listed in the RRULE `BYDAY` parameter. Events that violate this are fully functional via the API but cannot be loaded in the web schedule editor.
      - `members` ShiftMember[], required
        - `type` 'user_member' | 'empty_member', required — `user_member` — a specific user is assigned. `empty_member` — the slot is intentionally unassigned.
        - `user_id` string — The ID of the user. Required when type is `user_member`.

## Response `201`

Event created successfully

- EventResponse
  - `event` Event, required — An event defines when and how users are on-call within a rotation. It combines a recurring time window (`start_time`, `end_time`, `recurrence`) with an assignment strategy and an effective date range (`effective_since`, `effective_until`).
    - `id` string, required
    - `type` 'schedule_event', required
    - `name` string, required — Display name for this event
    - `start_time` ZonedDateTime, required — A time-of-day value with an explicit time zone. Used for event `start_time` and `end_time` to define the recurring window of coverage (e.g., 9 AM–5 PM every Monday in New York).
      - `date_time` string, date-time, required — The date and time
      - `time_zone` string, required — IANA timezone identifier
    - `end_time` ZonedDateTime, required — A time-of-day value with an explicit time zone. Used for event `start_time` and `end_time` to define the recurring window of coverage (e.g., 9 AM–5 PM every Monday in New York).
      - `date_time` string, date-time, required — The date and time
      - `time_zone` string, required — IANA timezone identifier
    - `effective_since` string, date-time, required — When this event starts producing shifts (UTC)
    - `effective_until` string, date-time, nullable — When this event stops producing shifts (UTC). Null means indefinite.
    - `recurrence` string[], required — RFC 5545 recurrence rules defining the repeating pattern. This must be an array containing: <br> - Exactly one <b>RRULE</b> <br>- Zero or more <b>EXDATE</b> <br>- Zero or more <b>RDATE</b>
    - `assignment_strategy` EventAssignmentStrategy, required — Defines how users are assigned on-call within an event's time window. - `rotating_member_assignment_strategy`: users rotate in sequence. `shifts_per_member` controls how many consecutive shift periods each member covers before rotating. - `every_member_assignment_strategy`: all listed members are on-call simultaneously for every occurrence.
      - `type` 'rotating_member_assignment_strategy' | 'every_member_assignment_strategy', required
      - `shifts_per_member` integer — Required for `rotating_member_assignment_strategy`. Number of consecutive shift occurrences each member covers before the next member takes over. **UI editor constraint:** When `recurrence` uses `FREQ=WEEKLY`, `shifts_per_member` must be evenly divisible by the number of days listed in the RRULE `BYDAY` parameter. Events that violate this are fully functional via the API but cannot be loaded in the web schedule editor.
      - `members` ShiftMember[], required
        - `type` 'user_member' | 'empty_member', required — `user_member` — a specific user is assigned. `empty_member` — the slot is intentionally unassigned.
        - `user_id` string — The ID of the user. Required when type is `user_member`.
    - `self` string, uri
    - `html_url` string, uri

## Other responses

- `400` — Bad Request — The request contains invalid parameters or data
- `401` — Caller did not supply credentials or did not provide the correct credentials. If you are using an API key, it may be invalid or your Authorization header may be malformed.
- `403` — Caller is not authorized to view the requested resource. While your authentication is valid, the authenticated user or token does not have permission to perform this action.
- `404` — The requested resource was not found.
- `500` — Internal Server Error the PagerDuty server experienced an error.

---

[API](https://skmtc.net/pagerduty/apis/rest-api.md) · [All operations](https://skmtc.net/pagerduty/apis/rest-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/pagerduty/rest-api/revisions/b679a8f3f02c/schema)