> ## Documentation Index > Fetch the complete documentation index at: https://docs.incident.io/llms.txt > Use this file to discover all available pages before exploring further. # List > List all replicas for a schedule. ## OpenAPI ````yaml /openapi/tags/schedule-replicas-v2.json get /v2/schedules/{schedule_id}/replicas openapi: 3.0.3 info: description: "This is the API reference for incident.io.\n\nIt documents available API endpoints, provides examples of how to use it, and\ninstructions around things like authentication and error handling.\n\nThe API is hosted at:\n\n- https://api.incident.io/\n\nAnd you will need to create an API key via your [incident.io\ndashboard](https://app.incident.io/settings/api-keys) to make requests.\n\n# Making requests\n\nHere are the key concepts required to make requests to the incident.io API.\n\n## Authentication\n\nFor all requests made to the incident.io API, you'll need an API key.\n\nTo create an API key, head to the incident dashboard and visit [API\nkeys](https://app.incident.io/settings/api-keys). When you create the key, you'll be able to choose what actions it\ncan take for your account: choose carefully, as those roles can only be set\nwhen you first create the key. We'll only show you the token once, so make sure\nyou store it somewhere safe.\n\nAPI keys are global to your incident.io account, and can be managed by anyone\nwho has the right permissions. We display the user that created the API key,\nand the API key will remain valid if that user becomes deactivated.\n\nOnce you have the key, you should make requests to the API that set the\n`Authorization` request header using a \"Bearer\" authentication scheme:\n\n```\nAuthorization: Bearer \n```\n\n## Rate Limits\n\nThe incident.io API enforces rate limits to ensure consistent performance for all users.\n\nThe default rate limit is 1200 requests/minute per API key. This limit applies to most endpoints across the API.\n\nSome endpoints have lower rate limits, particularly those that interact with external third-party systems that impose\ntheir own limitations. These specific limits vary by endpoint, and we recommend relying on the rate-limit error\nresponses to understand usage patterns and implement appropriate retry strategies.\n\nWhen you exceed a rate limit, the API will respond with a `429 Too Many Requests` status code, along with a JSON\nresponse that includes information about the limit and when you can retry:\n\n```json\n{\n \"type\": \"too_many_requests\",\n \"status\": 429,\n \"request_id\": \"b839a403-7704-41c1-bf6a-39a2d68caefa\",\n \"rate_limit\": {\n \"name\": \"api_key_name\",\n \"limit\": 1200,\n \"remaining\": 0,\n \"retry_after\": \"Thu, 17 Apr 2025 11:17:18 UTC\"\n },\n \"errors\": [\n {\n \"code\": \"too_many_requests\",\n \"message\": \"Too many requests hit the API too quickly. We recommend an exponential backoff of your requests.\"\n }\n ]\n}\n```\n\nThe response includes:\n* The name of the API key (`name`)\n* The bucket limit (`limit`)\n* The number of requests remaining (`remaining`)\n* When you can retry requests (`retry_after`)\n\n## Errors\n\nWe use standard HTTP response codes to indicate the status or failure of API\nrequests.\n\nThe API response body will be JSON, and contain more detailed information on the\nnature of the error.\n\nAn example error when a request is made without an API key:\n\n```json\n{\n \"type\": \"authentication_error\",\n \"status\": 401,\n \"request_id\": \"8e3cc412-b49d-4957-9073-2c19d2c61804\",\n \"errors\": [\n {\n \"code\": \"missing_authorization_material\",\n \"message\": \"No authorization material provided in request\"\n }\n ]\n}\n```\n\nNote that the error:\n\n- Contains the HTTP status (`401`)\n- References the type of error (`authentication_error`)\n- Includes a `request_id` that can be provided to incident.io support to help\n\tdebug questions with your API request\n- Provides a list of individual errors, which go into detail about why the error\n\toccurred\n\nThe most common error will be a 422 Validation Error, which is returned when the\nrequest was rejected due to failing validations.\n\nThese errors look like this:\n\n```json\n{\n \"type\": \"validation_error\",\n \"status\": 422,\n \"request_id\": \"631766c4-4afd-4803-997c-cd700928fa4b\",\n \"errors\": [\n {\n \"code\": \"is_required\",\n \"message\": \"A severity is required to open an incident\",\n \"source\": {\n \"field\": \"severity_id\"\n }\n }\n ]\n}\n```\n\nThis error is caused by not providing a severity identifier, which should be at\nthe `severity_id` field of the request payload. Errors like these can be mapped to\nforms, should you be integrating with the API from a user-interface.\n\n## Compatibility\n\nWe won't make breaking changes to existing API services or endpoints, but will\nexpect integrators to upgrade themselves to the latest API endpoints within 3\nmonths of us deprecating the old service.\n\nWe will make changes that are considered backwards compatible, which include:\n\n- Adding new API endpoints and services\n- Adding new properties to responses from existing API endpoints\n- Reordering properties returned from existing API endpoints\n- Adding optional request parameters to existing API endpoints\n- Altering the format or length of IDs\n- Adding new values to enums\n\nIt is important that clients are robust to these changes, to ensure reliable\nintegrations.\n\nAs an example, if you are generating a client using an openapi-generator, ensure\nthe generated client is configured to support unknown enum values, often\nconfigured via the `enumUnknownDefaultCase` parameter.\n\nWhen breaking changes are unavoidable, we'll create a new service version on a\nseparate path, and run them in parallel.\n\nFor example:\n\n- https://api.incident.io/v1/incidents\n- https://api.incident.io/v2/incidents\n\nFor any questions, email support@incident.io.\n" title: incident.io version: 1.0.0 servers: - url: https://api.incident.io security: - BearerAuth: [] tags: - description: > View and manage schedules. Manage your full schedule of on-call rotations, including the users and rotation configuration. name: Schedule Replicas V2 paths: /v2/schedules/{schedule_id}/replicas: get: tags: - Schedule Replicas V2 summary: List description: List all replicas for a schedule. operationId: Schedules V2_ListScheduleReplicas parameters: - description: The schedule to list replicas for example: 01FDAG4SAP5TYPT98WGR2N7W91 in: path name: schedule_id required: true schema: description: The schedule to list replicas for example: 01FDAG4SAP5TYPT98WGR2N7W91 type: string responses: '200': content: application/json: example: schedule_replicas: - created_at: '2021-08-17T13:28:57.801578Z' id: 01G0J1EXE7AXZ2C93K61WBPYEH last_sync_error: Failed to find external user for Milly last_synced_at: '2023-11-07T13:33:30Z' mirror_window_days: 14 replica_fallback_user_id: PA7AXXN replica_provider: pagerduty replica_provider_id: PO8107X schedule_id: 01FDAG4SAP5TYPT98WGR2N7W91 sources: - layer_id: 01G0J1EXE7AXZ2C93K61WBPYNH rotation_id: 01G0J1EXE7AXZ2C93K61WBPYEH updated_at: '2021-08-17T13:28:57.801578Z' user_statuses: - external_user_id: PJYTRGS user_id: 01G0J1EXE7AXZ2C93K61WBPYEH schema: $ref: '#/components/schemas/SchedulesListScheduleReplicasResultV2' description: OK response. components: schemas: SchedulesListScheduleReplicasResultV2: example: schedule_replicas: - created_at: '2021-08-17T13:28:57.801578Z' id: 01G0J1EXE7AXZ2C93K61WBPYEH last_sync_error: Failed to find external user for Milly last_synced_at: '2023-11-07T13:33:30Z' mirror_window_days: 14 replica_fallback_user_id: PA7AXXN replica_provider: pagerduty replica_provider_id: PO8107X schedule_id: 01FDAG4SAP5TYPT98WGR2N7W91 sources: - layer_id: 01G0J1EXE7AXZ2C93K61WBPYNH rotation_id: 01G0J1EXE7AXZ2C93K61WBPYEH updated_at: '2021-08-17T13:28:57.801578Z' user_statuses: - external_user_id: PJYTRGS user_id: 01G0J1EXE7AXZ2C93K61WBPYEH properties: schedule_replicas: example: - created_at: '2021-08-17T13:28:57.801578Z' id: 01G0J1EXE7AXZ2C93K61WBPYEH last_sync_error: Failed to find external user for Milly last_synced_at: '2023-11-07T13:33:30Z' mirror_window_days: 14 replica_fallback_user_id: PA7AXXN replica_provider: pagerduty replica_provider_id: PO8107X schedule_id: 01FDAG4SAP5TYPT98WGR2N7W91 sources: - layer_id: 01G0J1EXE7AXZ2C93K61WBPYNH rotation_id: 01G0J1EXE7AXZ2C93K61WBPYEH updated_at: '2021-08-17T13:28:57.801578Z' user_statuses: - external_user_id: PJYTRGS user_id: 01G0J1EXE7AXZ2C93K61WBPYEH items: $ref: '#/components/schemas/ScheduleReplicaV2' type: array required: - schedule_replicas type: object ScheduleReplicaV2: properties: created_at: description: When this schedule replica was first created example: '2021-08-17T13:28:57.801578Z' format: date-time type: string id: description: Unique identifier of the schedule replica example: 01G0J1EXE7AXZ2C93K61WBPYEH type: string last_sync_error: description: >- The most recent error encountered while syncing this replica to the external provider, if any. Common errors include unmapped users or connectivity issues with the external provider. Null if the last sync was successful. example: Failed to find external user for Milly type: string last_synced_at: description: >- When the replica was last successfully synced to the external provider. Null if the replica has never been successfully synced. example: '2023-11-07T13:33:30Z' format: date-time type: string mirror_window_days: description: >- How many days ahead to mirror this schedule into the external provider. Defaults to 14 if not set; maximum 90. example: 14 format: int64 maximum: 90 minimum: 1 type: integer replica_fallback_user_id: description: >- The ID of a user in the external provider that will be assigned whenever nobody is on-call in the incident.io schedule. External providers typically require someone to always be on-call, so this user fills gaps where incident.io has no one scheduled. example: PA7AXXN type: string replica_provider: description: The external provider where this schedule is replicated to enum: - native - pagerduty - opsgenie - jira example: pagerduty type: string replica_provider_id: description: >- The ID of the schedule in the external provider that this replica syncs to. For PagerDuty this is the schedule ID (e.g. PO8107X), for Opsgenie the schedule ID, and for Jira Service Management the schedule ID. example: PO8107X type: string schedule_id: description: The ID of the incident.io schedule that this replica is syncing from example: 01FDAG4SAP5TYPT98WGR2N7W91 type: string sources: description: >- The specific rotation and layer combinations from the schedule that are being replicated. Each source identifies a single layer within a rotation to sync to the external provider. example: - layer_id: 01G0J1EXE7AXZ2C93K61WBPYNH rotation_id: 01G0J1EXE7AXZ2C93K61WBPYEH items: $ref: '#/components/schemas/ScheduleReplicaSourceV2' type: array updated_at: description: When this schedule replica was last updated example: '2021-08-17T13:28:57.801578Z' format: date-time type: string user_statuses: description: >- The mapping status of each incident.io user in the schedule to their corresponding user in the external provider. Users must be mapped for the replica to sync their on-call shifts correctly. example: - external_user_id: PJYTRGS user_id: 01G0J1EXE7AXZ2C93K61WBPYEH items: $ref: '#/components/schemas/ScheduleReplicaUserStatusV2' type: array required: - id - schedule_id - sources - replica_provider - replica_provider_id - replica_fallback_user_id - user_statuses - created_at - updated_at type: object ScheduleReplicaSourceV2: example: layer_id: 01G0J1EXE7AXZ2C93K61WBPYNH rotation_id: 01G0J1EXE7AXZ2C93K61WBPYEH properties: layer_id: description: >- The ID of the layer within the rotation to replicate. Rotations can have multiple layers that stack on top of each other, and you must specify which layer to replicate. example: 01G0J1EXE7AXZ2C93K61WBPYNH type: string rotation_id: description: >- The ID of the rotation within the schedule to replicate. Each schedule can have multiple rotations, and you can choose which ones to include in the replica. example: 01G0J1EXE7AXZ2C93K61WBPYEH type: string required: - rotation_id - layer_id type: object ScheduleReplicaUserStatusV2: example: external_user_id: PJYTRGS user_id: 01G0J1EXE7AXZ2C93K61WBPYEH properties: external_user_id: description: >- The corresponding user ID in the external provider (e.g. a PagerDuty user ID). If set, the user has been successfully mapped to an external user and will be included in the replica. If null, the user could not be resolved and syncing may produce errors. example: PJYTRGS type: string user_id: description: >- The incident.io user ID for a user who appears in the schedule rotation. example: 01G0J1EXE7AXZ2C93K61WBPYEH type: string required: - user_id type: object securitySchemes: BearerAuth: type: http scheme: bearer description: API key from your incident.io dashboard (Settings → API keys) ````