> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # Updates the team's alert configuration ## OpenAPI ````yaml https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json put /v1/alert_configuration openapi: 3.0.1 info: title: Rootly API v1 version: v1 license: name: Rootly url: https://rootly.com description: >+ # How to generate an API Key? - **Organization dropdown** > **Organization Settings** > **API Keys** # JSON:API Specification Rootly is using **JSON:API** (https://jsonapi.org) specification: - JSON:API is a specification for how a client should request that resources be fetched or modified, and how a server should respond to those requests. - JSON:API is designed to minimize both the number of requests and the amount of data transmitted between clients and servers. This efficiency is achieved without compromising readability, flexibility, or discoverability. - JSON:API requires use of the JSON:API media type (**application/vnd.api+json**) for exchanging data. # Authentication and Requests We use standard HTTP Authentication over HTTPS to authorize your requests. ``` curl --request GET \ --header 'Content-Type: application/vnd.api+json' \ --header 'Authorization: Bearer YOUR-TOKEN' \ --url https://api.rootly.com/v1/incidents ```
# Rate limiting - There is a default limit of **5** **GET**, **HEAD**, and **OPTIONS** calls **per API key** every **60 seconds** (0 hours). The limit is calculated over a **0-hour sliding window** looking back from the current time. While the limit can be configured to support higher thresholds, you must first contact your **Rootly Customer Success Manager** to make any adjustments. - There is a default limit of **3** **POST**, **PUT**, **PATCH** or **DELETE** calls **per API key** every **60 seconds** (0 hours). The limit is calculated over a **0-hour sliding window** looking back from the current time. While the limit can be configured to support higher thresholds, you must first contact your **Rootly Customer Success Manager** to make any adjustments. - When rate limits are exceeded, the API will return a **429 Too Many Requests** HTTP status code with the response: `{"error": "Rate limit exceeded. Try again later."}` - **X-RateLimit headers** are included in every API response, providing real-time rate limit information: - **X-RateLimit-Limit** - The maximum number of requests permitted and the time window (e.g., "1000, 1000;window=3600" for 1000 requests per hour) - **X-RateLimit-Remaining** - The number of requests remaining in the current rate limit window - **X-RateLimit-Used** - The number of requests already made in the current window - **X-RateLimit-Reset** - The time at which the current rate limit window resets, in UTC epoch seconds # Pagination - Pagination is supported for all endpoints that return a collection of items. - Pagination is controlled by the **page** query parameter ## Example ``` curl --request GET \ --header 'Content-Type: application/vnd.api+json' \ --header 'Authorization: Bearer YOUR-TOKEN' \ --url https://api.rootly.com/v1/incidents?page[number]=1&page[size]=10 ``` x-logo: url: https://rootly-heroku.s3.us-east-1.amazonaws.com/swagger/v1/logo.png servers: - url: https://api.rootly.com security: [] paths: /v1/alert_configuration: put: tags: - AlertConfiguration summary: Updates the team's alert configuration operationId: updateAlertConfiguration parameters: [] requestBody: content: application/vnd.api+json: schema: $ref: '#/components/schemas/update_alert_configuration' required: true responses: '200': description: alert configuration updated content: application/vnd.api+json: schema: $ref: '#/components/schemas/alert_configuration_response' '403': description: an attribute's feature is not enabled for the team content: application/vnd.api+json: schema: $ref: '#/components/schemas/errors_list' '404': description: team has no alert configuration content: application/vnd.api+json: schema: $ref: '#/components/schemas/errors_list' '422': description: the settings are invalid content: application/vnd.api+json: schema: $ref: '#/components/schemas/errors_list' security: - bearer_auth: [] components: schemas: update_alert_configuration: type: object properties: data: type: object properties: id: type: string description: >- Accepted for JSON:API client compatibility, but ignored. Each team has a single alert configuration, so no id is needed. type: type: string enum: - alert_configurations attributes: type: object description: >- Every attribute is optional and replaces its stored value. An attribute whose feature is not enabled for the team is refused with 403. properties: alert_acknowledgment: type: object description: >- Re-trigger behaviour for acknowledged alerts. Replaces the stored object as a whole. properties: timeout_enabled: type: boolean description: Re-trigger an acknowledged alert after the timeout. timeout_minutes: type: integer description: Minutes before an acknowledged alert re-triggers. enum: - 10 - 20 - 30 - 40 - 50 - 60 - 90 - 120 - 180 - 240 - 300 - 360 - 720 - 1440 retrigger_manual_alerts: type: boolean description: >- Whether alerts created from a manual page also re-trigger. Changing it is rejected with 422 until the manual page re-trigger opt-out is enabled for the team. additionalProperties: false manual_paging_form_settings: type: array description: >- Stored entity types for the manual paging form, as configured; at least one is required. The form itself may hide a type the team cannot use yet, such as functionality. items: type: string enum: - user - team - service - functionality - escalation_policy minItems: 1 manual_paging_urgency_ids: type: array description: >- Alert urgency ids allowed when manually paging. Empty means all; deleted urgencies are left out. Present and accepted only while the manual-page-urgency-allowlist feature is on for the team. items: type: string format: uuid default_user_notification_settings: type: object description: >- Channel defaults for new users, per urgency level. Omitted levels keep the built-in defaults; existing users are never changed. Present and accepted only while org-default-notification-settings is on for the team. properties: audible_contact_types: type: array description: >- Channels enabled on a newly created user's audible notification rule. At least one channel is required. minItems: 1 uniqueItems: true items: type: string enum: - email - device - sms - call quiet_contact_types: type: array description: >- Channels enabled on a newly created user's quiet notification rule. At least one channel is required. minItems: 1 uniqueItems: true items: type: string enum: - email - non_critical_device - sms - call additionalProperties: false additionalProperties: false additionalProperties: false required: - type - attributes additionalProperties: false required: - data alert_configuration_response: type: object properties: data: type: object properties: id: type: string description: Unique ID of the alert_configuration type: type: string enum: - alert_configurations attributes: type: object allOf: - $ref: '#/components/schemas/alert_configuration' required: - id - type - attributes required: - data errors_list: type: object properties: errors: type: array items: type: object properties: title: type: string status: type: string code: type: string nullable: true detail: type: string nullable: true required: - title - status alert_configuration: type: object properties: alert_acknowledgment: type: object description: >- Re-trigger behaviour for acknowledged alerts. Replaces the stored object as a whole. properties: timeout_enabled: type: boolean description: Re-trigger an acknowledged alert after the timeout. timeout_minutes: type: integer description: Minutes before an acknowledged alert re-triggers. enum: - 10 - 20 - 30 - 40 - 50 - 60 - 90 - 120 - 180 - 240 - 300 - 360 - 720 - 1440 retrigger_manual_alerts: type: boolean description: >- Whether alerts created from a manual page also re-trigger. Changing it is rejected with 422 until the manual page re-trigger opt-out is enabled for the team. additionalProperties: false manual_paging_form_settings: type: array description: >- Stored entity types for the manual paging form, as configured; at least one is required. The form itself may hide a type the team cannot use yet, such as functionality. items: type: string enum: - user - team - service - functionality - escalation_policy manual_paging_urgency_ids: type: array description: >- Alert urgency ids allowed when manually paging. Empty means all; deleted urgencies are left out. Present and accepted only while the manual-page-urgency-allowlist feature is on for the team. items: type: string format: uuid default_user_notification_settings: type: object description: >- Channel defaults for new users, per urgency level. Omitted levels keep the built-in defaults; existing users are never changed. Present and accepted only while org-default-notification-settings is on for the team. properties: audible_contact_types: type: array description: >- Channels enabled on a newly created user's audible notification rule. At least one channel is required. minItems: 1 uniqueItems: true items: type: string enum: - email - device - sms - call quiet_contact_types: type: array description: >- Channels enabled on a newly created user's quiet notification rule. At least one channel is required. minItems: 1 uniqueItems: true items: type: string enum: - email - non_critical_device - sms - call additionalProperties: false created_at: type: string format: date-time updated_at: type: string format: date-time securitySchemes: bearer_auth: type: http scheme: bearer ````