### Setup Local Testing Environment with Bash

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/CLAUDE.md

Installs the built provider into a local Terraform plugins directory for testing. Requires the `make` utility and appropriate filesystem permissions. After execution, Terraform can load the provider from the specified path.

```bash
# Build and install locally for testing
make build
mkdir -p ~/.terraform.d/plugins/terraform.local/local/rootly/1.0.0/darwin_arm64/
cp terraform-provider-rootly ~/.terraform.d/plugins/terraform.local/local/rootly/1.0.0/darwin_arm64/terraform-provider-rootly_v1.0.0
```

--------------------------------

### Example Version Management Workflow

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/README.md

Demonstrates checking current version, bumping patch version, and releasing in one step. Shows the complete workflow from version checking to CI-triggered release.

```bash
# Check current version
make version-show
# Current version: v3.1.0
# Next patch: 3.1.1

# Bump patch version
make version-patch
# Creates and pushes v3.1.1 tag

# Or bump and push tag in one step (triggers CI release)
make release-patch
# Bumps to v3.1.1, pushes tag, CI builds and publishes release
```

--------------------------------

### Import rootly_workflow_task_create_go_to_meeting (Terraform)

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_create_go_to_meeting.md

Shows an example of importing a rootly_workflow_task_create_go_to_meeting resource using an import block within a Terraform configuration.

```terraform
import {
  to = rootly_workflow_task_create_go_to_meeting.primary
  id = "a816421c-6ceb-481a-87c4-585e47451f24"
}
```

--------------------------------

### Bash Local Development Setup for Provider Testing

Source: https://context7.com/rootlyhq/terraform-provider-rootly/llms.txt

Sets up a local environment to build and test the provider binary without publishing. Involves creating a plugin directory, copying the binary, configuring .terraform.rc for filesystem mirror, and defining a sample Terraform config in main.tf to initialize, plan, and apply. Ensures local source and version are used for isolated testing.

```bash
# Build provider binary
make build

# Create local plugin directory
mkdir -p ~/.terraform.d/plugins/terraform.local/local/rootly/1.0.0/darwin_arm64/

# Copy provider binary
cp terraform-provider-rootly \
  ~/.terraform.d/plugins/terraform.local/local/rootly/1.0.0/darwin_arm64/terraform-provider-rootly_v1.0.0

# Configure ~/.terraform.rc for local testing
cat > ~/.terraform.rc << 'EOF'
provider_installation {
  filesystem_mirror {
    path = "~/.terraform.d/plugins"
  }
  direct {
    exclude = ["terraform.local/*/*"]
  }
}
EOF

# Use local provider in Terraform configuration
cat > main.tf << 'EOF'
terraform {
  required_providers {
    rootly = {
      source  = "terraform.local/local/rootly"
      version = "1.0.0"
    }
  }
}

provider "rootly" {}

resource "rootly_service" "test" {
  name = "test-service"
}
EOF

# Test the local provider
terraform init
terraform plan
terraform apply
```

--------------------------------

### CRUD Operations on Services Using Rootly Go Client

Source: https://context7.com/rootlyhq/terraform-provider-rootly/llms.txt

This Go example initializes a Rootly client and performs create, read, update, delete (CRUD) operations on services, including listing all services. It requires the Rootly API URL, token, and user agent; inputs are service structs with fields like name, description, and notifications; outputs are service objects or errors. Limitations: API token must have appropriate permissions, and error handling is via log.Fatal for simplicity.

```go
package main

import (
    "fmt"
    "log"

    "github.com/rootlyhq/terraform-provider-rootly/v2/client"
    rootlygo "github.com/rootlyhq/terraform-provider-rootly/v2/schema"
)

func main() {
    // Initialize client
    c, err := client.NewClient(
        "https://api.rootly.com",
        "your-api-token",
        "TerraformProvider/4.3.3",
    )
    if err != nil {
        log.Fatal(err)
    }

    // Create a service
    newService := &client.Service{
        Name:        "payment-gateway",
        Description: "Payment processing service",
        Color:       "#FF5733",
        NotifyEmails: []interface{}{
            "payments@acme.com",
            "sre@acme.com",
        },
        SlackChannels: []interface{}{
            map[string]interface{}{
                "id":   "C123ABC",
                "name": "payments-alerts",
            },
        },
    }

    service, err := c.CreateService(newService)
    if err != nil {
        log.Fatalf("Failed to create service: %v", err)
    }
    fmt.Printf("Created service: %s (ID: %s)\n", service.Name, service.ID)

    // List all services
    params := &rootlygo.ListServicesParams{}
    services, err := c.ListServices(params)
    if err != nil {
        log.Fatalf("Failed to list services: %v", err)
    }

    for _, svc := range services {
        s := svc.(*client.Service)
        fmt.Printf("Service: %s (Slug: %s)\n", s.Name, s.Slug)
    }

    // Get specific service
    service, err = c.GetService(service.ID)
    if err != nil {
        log.Fatalf("Failed to get service: %v", err)
    }
    fmt.Printf("Retrieved: %s\n", service.Name)

    // Update service
    service.Description = "Updated payment processing service"
    service.Color = "#00FF00"

    updated, err := c.UpdateService(service.ID, service)
    if err != nil {
        log.Fatalf("Failed to update service: %v", err)
    }
    fmt.Printf("Updated service description: %s\n", updated.Description)

    // Delete service
    err = c.DeleteService(service.ID)
    if err != nil {
        log.Fatalf("Failed to delete service: %v", err)
    }
    fmt.Println("Service deleted successfully")
}
```

--------------------------------

### Import rootly_workflow_task_create_datadog_notebook resource using Terraform CLI

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_create_datadog_notebook.md

Provides commands to import an existing rootly_workflow_task_create_datadog_notebook into the Terraform state. Requires Terraform installed and access to the Rootly API. The import can be performed via the CLI command or an import block in HCL.

```sh
terraform import rootly_workflow_task_create_datadog_notebook.primary a816421c-6ceb-481a-87c4-585e47451f24
```

```terraform
import {\n  to = rootly_workflow_task_create_datadog_notebook.primary\n  id = \"a816421c-6ceb-481a-87c4-585e47451f24\"\n}
```

--------------------------------

### Import rootly_workflow_task_create_google_docs_page

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_create_google_docs_page.md

Provides examples for importing an existing rootly_workflow_task_create_google_docs_page resource into Terraform state. The import can be done using either the terraform import command or an import block. Requires the resource ID which can be found in the web app or retrieved via API.

```shell
terraform import rootly_workflow_task_create_google_docs_page.primary a816421c-6ceb-481a-87c4-585e47451f24
```

```hcl
import {
  to = rootly_workflow_task_create_google_docs_page.primary
  id = "a816421c-6ceb-481a-87c4-585e47451f24"
}
```

```shell
terraform plan -generate-config-out=generated.tf
```

--------------------------------

### Terraform Rootly Service Resource Example

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/service.md

This snippet demonstrates how to define and configure a Rootly service resource in Terraform. It includes essential fields like name, color, notification emails, and Slack channel/alias mappings. This resource is used to represent and manage services within the Rootly platform.

```Terraform
resource "rootly_service" "elasticsearch_prod" {
  name          = "elasticsearch-prod"
  color         = "#800080"
  notify_emails = ["foo@acme.com", "bar@acme.com"]
  slack_aliases {
    id   = "S0614TZR7"
    name = "Alias 1" // Any string really
  }
  slack_channels {
    id   = "C06A4RZR9"
    name = "Channel 1" // Any string really
  }
  slack_channels {
    id   = "C02T4RYR2"
    name = "Channel 2" // Any string really
  }
}

resource "rootly_service" "customer_postgresql_prod" {
  name          = "customer-postgresql-prod"
  color         = "#800080"
  notify_emails = ["foo@acme.com", "bar@acme.com"]
  slack_aliases {
    id   = "S0614TZR7"
    name = "Alias 1" // Any string really
  }
  slack_channels {
    id   = "C06A4RZR9"
    name = "Channel 1" // Any string really
  }
  slack_channels {
    id   = "C02T4RYR2"
    name = "Channel 2" // Any string really
  }
}
```

--------------------------------

### Jira Integration Workflow - Terraform

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/index.md

Creates automated Jira issue workflow for incident management. Opens Jira tickets when incidents start with dynamic title, description, and labels. Uses template variables for incident data injection.

```terraform
# Jira workflow
resource "rootly_workflow_incident" "jira" {
  name        = "Create a Jira Issue"
  description = "Open Jira ticket whenever incident starts"
  trigger_params {
    triggers                  = ["incident_created"]
    incident_condition_kind   = "IS"
    incident_kinds            = ["normal"]
    incident_condition_status = "IS"
    incident_statuses         = ["started"]
  }
  enabled = true
}

resource "rootly_workflow_task_create_jira_issue" "jira" {
  workflow_id = rootly_workflow_incident.jira.id
  task_params {
    title       = "{{ incident.title }}"
    description = "{{ incident.summary }}"
    project_key = "ROOT"
    issue_type = {
      id   = "10001"
      name = "Task"
    }
    status = {
      id   = "10000"
      name = "To Do"
    }
    labels = "{{ incident.environment_slugs | concat: incident.service_slugs | concat: incident.functionality_slugs | concat: incident.group_slugs | join: \",\" }}"
  }
}
```

--------------------------------

### Import Rootly Workflow Task Get Alerts via Terraform CLI

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_get_alerts.md

Uses the Terraform CLI to import an existing rootly_workflow_task_get_alerts resource into the state. Requires Terraform installed and the resource ID. After execution, the resource will be tracked by Terraform.

```sh
terraform import rootly_workflow_task_get_alerts.primary a816421c-6ceb-481a-87c4-585e47451f24
```

--------------------------------

### Import existing rootly_team into Terraform state (Shell)

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/team.md

Shows the CLI command to import an existing rootly_team resource into the Terraform state using its unique identifier. Requires Terraform installed and access to the target Rootly account.

```shell
terraform import rootly_team.primary a816421c-6ceb-481a-87c4-585e47451f24
```

--------------------------------

### Set up alert routing rule with condition groups

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/alert_routing_rule.md

This example shows how to use condition groups for complex alert routing logic. It allows grouping multiple conditions with specific ordering and evaluation logic.

```hcl
resource "rootly_alert_routing_rule" "with_condition_groups" {
  alerts_source_id = "source-id"
  name             = "Rule with Condition Groups"

  destination {
    target_type = "EscalationPolicy"
    target_id   = "policy-id"
  }

  condition_groups {
    position = 1
    conditions {
      property_field_name           = "description"
      property_field_type           = "attribute"
      property_field_condition_type = "matches_regex"
      property_field_value          = "[Ee]xception"
    }
  }
}
```

--------------------------------

### Import rootly workflow task using Terraform CLI and import block

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_create_watsonx_chat_completion.md

Shows how to import an existing rootly_workflow_task_create_watsonx_chat_completion resource into Terraform state. The import can be performed via a CLI command or an HCL import block. Requires the resource's unique identifier and Terraform installed.

```Shell
terraform import rootly_workflow_task_create_watsonx_chat_completion.primary a816421c-6ceb-481a-87c4-585e47451f24
```

```Terraform
import {
  to = rootly_workflow_task_create_watsonx_chat_completion.primary
  id = "a816421c-6ceb-481a-87c4-585e47451f24"
}
```

--------------------------------

### Terraform rootly_alert_group Example

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/alert_group.md

This code snippet demonstrates how to configure a rootly alert group using Terraform. It defines the alert group's name, condition type, time window, and target information. This resource is used for managing and configuring alert groups within the Rootly platform.

```terraform
resource "rootly_alert_group" "example" {
  name                 = "Alert group"
  condition_type       = "all"
  time_window          = 10
  group_by_alert_title = true

  attributes {
    json_path = "$.title"
  }

  targets {
    target_type = "Service"
    target_id   = "<Service UUID>"
  }
}
```

--------------------------------

### Creating Rootly Schedule with Weekday Rotation in Terraform

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/schedule.md

This example creates a primary on-call schedule, fetches users via data sources, defines a weekday rotation with custom active times, sets active days for Monday through Friday from 10:00 to 18:00, and assigns users to positions in the rotation. It requires the rootly_user data source and configures time zones and handoff notes. Limitations include manual definition of each active day and dependency on user IDs.

```hcl
data "rootly_user" "john" {
  email = "demo@rootly.com"
}

data "rootly_user" "jane" {
  email = "demo1@rootly.com"
}

resource "rootly_schedule" "primary" {
  name              = "Primary On-Call Schedule"
  owner_user_id     = data.rootly_user.john.id
  all_time_coverage = false
}

resource "rootly_schedule_rotation" "weekdays" {
  schedule_id     = rootly_schedule.primary.id
  name            = "weekdays"
  active_all_week = false
  active_days = [
    "M",
    "T",
    "W",
    "R",
    "F",
  ]
  active_time_type = "custom"
  position         = 1
  schedule_rotationable_attributes = {
    handoff_time = "T",
    handoff_time = "10:00"
  }
  schedule_rotationable_type = "ScheduleWeeklyRotation"
  time_zone                  = "America/Toronto"
}

# Define active days for the weekday rotation
# Monday
resource "rootly_schedule_rotation_active_day" "m1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "M"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
# Tuesday
resource "rootly_schedule_rotation_active_day" "t1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "T"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
# Wednesday
resource "rootly_schedule_rotation_active_day" "w1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "W"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
# Thursday
resource "rootly_schedule_rotation_active_day" "th1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "R"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
# Friday
resource "rootly_schedule_rotation_active_day" "f1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "F"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}

resource "rootly_schedule_rotation_user" "john" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  position             = 1
  user_id              = data.rootly_user.john.id
}

resource "rootly_schedule_rotation_user" "jane" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  position             = 2
  user_id              = data.rootly_user.jane.id
}
```

--------------------------------

### Import Terraform resource via CLI command

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/incident_role.md

Imports an existing rootly_incident_role resource into Terraform state using the terraform import command. Requires Terraform CLI installed and the resource ID. Updates the state file with the imported resource.

```shell
terraform import rootly_incident_role.primary a816421c-6ceb-481a-87c4-585e47451f24
```

--------------------------------

### Import Rootly Alert Urgency Resource using Terraform CLI

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/alert_urgency.md

This snippet demonstrates how to import an existing Rootly alert urgency resource into Terraform state. It uses the terraform import command in shell script or an import block in HCL. Requires the resource ID, which can be found in the Rootly web app or via API. Terraform CLI must be installed, and you need access to the Rootly provider. Limitations include that the resource must already exist in Rootly.

```shell
terraform import rootly_alert_urgency.primary a816421c-6ceb-481a-87c4-585e47451f24
```

```hcl
import {
  to = rootly_alert_urgency.primary
  id = "a816421c-6ceb-481a-87c4-585e47451f24"
}
```

--------------------------------

### Create Jira Issue Workflow Task in Terraform

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_create_jira_issue.md

This example shows how to define a Terraform resource for a workflow that creates a Jira issue when an incident is started. It depends on the terraform-provider-rootly and requires a parent workflow incident. Inputs include workflow ID, task parameters like title and project key; outputs the created Jira issue. Limitations: Requires valid Jira integration setup and may fail if API credentials are invalid.

```terraform
resource "rootly_workflow_incident" "jira" {
  name        = "Create a Jira Issue"
  description = "Open Jira ticket whenever incident starts"
  trigger_params {
    triggers                  = ["incident_created"]
    incident_condition_kind   = "IS"
    incident_kinds            = ["normal"]
    incident_condition_status = "IS"
    incident_statuses         = ["started"]
  }
  enabled = true
}

resource "rootly_workflow_task_create_jira_issue" "jira" {
  workflow_id     = rootly_workflow_incident.jira.id
  skip_on_failure = false
  enabled         = true
  task_params {
    title       = "{{ incident.title }}"
    description = "{{ incident.summary }}"
    project_key = "ROOT"
    issue_type = {
      id   = "10001"
      name = "Task"
    }
    status = {
      id   = "10000"
      name = "To Do"
    }
    labels = "{{ incident.environment_slugs | concat: incident.service_slugs | concat: incident.functionality_slugs | concat: incident.group_slugs | join: \",\" }}"
  }
}
```

--------------------------------

### Bash Commands for Building and Code Generation

Source: https://context7.com/rootlyhq/terraform-provider-rootly/llms.txt

Provides Makefile targets to build the provider, regenerate code from OpenAPI schema, compile, and run tests. Full build downloads schema and generates docs; separate targets for codegen, docs, and quick builds. Acceptance tests require environment variables TF_ACC=1 and ROOTLY_API_TOKEN for valid credentials.

```bash
# Full build: download schema, generate code, compile, regenerate docs
make build

# Only regenerate code from schema (no compilation)
make codegen

# Only regenerate documentation
make docs

# Quick local build without code generation
go build -o terraform-provider-rootly

# Run unit tests
make test

# Run acceptance tests (requires TF_ACC=1 and valid API credentials)
export TF_ACC=1
export ROOTLY_API_TOKEN="your-token"
make testacc
```

--------------------------------

### Import Rootly Workflow Task Resource via Terraform Command

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_page_opsgenie_on_call_responders.md

Imports a Rootly workflow task resource using the Terraform CLI import command. Requires the resource ID, which can be found in the web app or via API. This command adds the resource to the Terraform state without creating configuration. Use in shell environments with Terraform installed as a dependency. Outputs the imported resource to the state file; does not modify HCL configuration. Limited to importing one resource at a time and assumes correct Terraform setup.

```shell
terraform import rootly_workflow_task_page_opsgenie_on_call_responders.primary a816421c-6ceb-481a-87c4-585e47451f24
```

--------------------------------

### GET /api/workflows/{id}

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_post_mortem.md

Retrieve the configuration details of a specific post-mortem workflow using its unique identifier.

```APIDOC
## GET /api/workflows/{id}

### Description
Retrieves the detailed configuration and current state of a specific post-mortem workflow.

### Method
GET

### Endpoint
/api/workflows/{id}

### Parameters
#### Path Parameters
- **id** (String) - Required - Unique identifier of the workflow

### Response
#### Success Response (200)
- **id** (String) - Unique identifier of the workflow
- **name** (String) - Title of the workflow
- **description** (String) - Description of the workflow
- **enabled** (Boolean) - Whether the workflow is enabled
- **command** (String) - Workflow command
- **command_feedback_enabled** (Boolean) - Feedback notification status

#### Response Example
{
  "id": "wf_abc123",
  "name": "Post-Incident Review",
  "description": "Automated review process after major incidents",
  "enabled": true,
  "command": "run_review_process.sh",
  "command_feedback_enabled": true
}
```

--------------------------------

### Create Services with Integrations - Terraform

Source: https://context7.com/rootlyhq/terraform-provider-rootly/llms.txt

Defines services in Rootly with integrations to Slack, PagerDuty, and GitHub. Includes notification settings and external system links.

```terraform
resource "rootly_service" "elasticsearch_prod" {
  name          = "elasticsearch-prod"
  description   = "Production Elasticsearch cluster"
  color         = "#800080"
  notify_emails = ["sre-team@acme.com", "ops@acme.com"]

  # Link to Slack channels for notifications
  slack_channels {
    id   = "C06A4RZR9"
    name = "elasticsearch-alerts"
  }

  slack_channels {
    id   = "C02T4RYR2"
    name = "sre-incidents"
  }

  # Slack user group aliases for @mentions
  slack_aliases {
    id   = "S0614TZR7"
    name = "sre-team"
  }

  # External system integrations
  pagerduty_id         = "PZYX123"
  github_repository    = "acme/elasticsearch-infra"
  github_branch        = "main"
}

resource "rootly_environment" "production" {
  name        = "Production"
  description = "Production environment"
  color       = "#FF0000"
  notify_emails = ["engineering@acme.com"]
}

resource "rootly_functionality" "search" {
  name        = "Search"
  description = "Search functionality across products"
  color       = "#00FF00"
}
```

--------------------------------

### GET /incidents

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/data-sources/incident.md

Retrieves Rootly incident data using optional filter parameters defined in the Terraform data source.

```APIDOC
## GET /incidents

### Description
Retrieves Rootly incident data based on the supplied filter criteria.

### Method
GET

### Endpoint
/incidents

### Parameters
#### Query Parameters
- **acknowledged_at[lt]** (string) - Optional - Filter incidents with acknowledged_at less than the specified timestamp.
- **acknowledged_at[gt]** (string) - Optional - Filter incidents with acknowledged_at greater than the specified timestamp.
- **closed_at[lt]** (string) - Optional - Filter incidents with closed_at less than the specified timestamp.
- **closed_at[gt]** (string) - Optional - Filter incidents with closed_at greater than the specified timestamp.
- **created_at[lt]** (string) - Optional - Filter incidents with created_at less than the specified timestamp.
- **created_at[gt]** (string) - Optional - Filter incidents with created_at greater than the specified timestamp.
- **detected_at[lt]** (string) - Optional - Filter incidents with detected_at less than the specified timestamp.
- **detected_at[gt]** (string) - Optional - Filter incidents with detected_at greater than the specified timestamp.
- **in_triage_at[lt]** (string) - Optional - Filter incidents with in_triage_at less than the specified timestamp.
- **in_triage_at[gt]** (string) - Optional - Filter incidents with in_triage_at greater than the specified timestamp.
- **mitigated_at[lt]** (string) - Optional - Filter incidents with mitigated_at less than the specified timestamp.
- **mitigated_at[gt]** (string) - Optional - Filter incidents with mitigated_at greater than the specified timestamp.
- **resolved_at[lt]** (string) - Optional - Filter incidents with resolved_at less than the specified timestamp.
- **resolved_at[gt]** (string) - Optional - Filter incidents with resolved_at greater than the specified timestamp.
- **started_at[lt]** (string) - Optional - Filter incidents with started_at less than the specified timestamp.
- **started_at[gt]** (string) - Optional - Filter incidents with started_at greater than the specified timestamp.
- **updated_at[lt]** (string) - Optional - Filter incidents with updated_at less than the specified timestamp.
- **updated_at[gt]** (string) - Optional - Filter incidents with updated_at greater than the specified timestamp.
- **environments** (string) - Optional - Filter by environment name.
- **functionalities** (string) - Optional - Filter by functionality name.
- **kind** (string) - Optional - Filter by incident kind.
- **labels** (string) - Optional - Filter by labels.
- **private** (boolean) - Optional - Filter by privacy flag.
- **services** (string) - Optional - Filter by service name.
- **severity** (string) - Optional - Filter by severity level.
- **status** (string) - Optional - Filter by incident status.
- **user** (string) - Optional - Filter by user identifier.

### Request Example
GET /incidents?status=opened&severity=high

### Response
#### Success Response (200)
- **id** (string) - Incident identifier.
- **slug** (string) - Human‑readable incident slug.
- **status** (string) - Current status of the incident.
- **severity** (string) - Severity of the incident.
- **created_at** (string) - Creation timestamp.

### Response Example
{
  "incidents": [
    {
      "id": "inc_123",
      "slug": "my-incident-slug",
      "status": "open",
      "severity": "high",
      "created_at": "2023-01-01T12:00:00Z"
    }
  ]
}
```

--------------------------------

### Import Terraform Resource - terraform-provider-rootly

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_simple.md

Demonstrates how to import the rootly_workflow_simple resource into Terraform state using both CLI commands and HCL import blocks. Includes methods for generating configuration from existing resources.

```HCL
import {
  to = rootly_workflow_simple.primary
  id = "a816421c-6ceb-481a-87c4-585e47451f24"
}
```

```bash
terraform import rootly_workflow_simple.primary a816421c-6ceb-481a-87c4-585e47451f24
```

```bash
terraform plan -generate-config-out=generated.tf
```

--------------------------------

### GET rootly_custom_field

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/data-sources/custom_field.md

Retrieves details of a custom field using its slug. This data source is deprecated in favor of form_field.

```APIDOC
## GET /rootly_custom_field

### Description
Retrieves details of a custom field using its slug. This data source is deprecated in favor of form_field.

### Method
GET

### Endpoint
/rootly_custom_field

### Parameters
#### Query Parameters
- **slug** (String) - Required - The slug of the custom field to retrieve
- **created_at** (Map of String) - Optional - Filter by date range using 'lt' and 'gt'
- **enabled** (Boolean) - Optional - Filter by enabled status
- **kind** (String) - Optional - Filter by field kind
- **label** (String) - Optional - Filter by field label

### Response
#### Success Response (200)
- **id** (String) - The ID of this resource
- **slug** (String) - The slug of the custom field
- **label** (String) - The display label of the field
- **kind** (String) - The type/kind of field
- **enabled** (Boolean) - Whether the field is enabled

#### Response Example
{
  "id": "12345",
  "slug": "my-custom-field",
  "label": "My Custom Field",
  "kind": "text",
  "enabled": true
}
```

--------------------------------

### Version Management Commands

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/README.md

Commands for managing semantic versions of the provider. These commands ensure version consistency and proper validation. Use these instead of manually creating git tags.

```bash
make version-show      # Show current and next versions
make version-patch     # Bump patch version (1.2.3 → 1.2.4)
make version-minor     # Bump minor version (1.2.3 → 1.3.0)
make version-major     # Bump major version (1.2.3 → 2.0.0)
```

--------------------------------

### Bash Version Management and Release Commands

Source: https://context7.com/rootlyhq/terraform-provider-rootly/llms.txt

Uses Makefile targets to show current version, bump patch/minor/major semantically, create git tags, and trigger CI releases via GitHub Actions. Release commands build multi-platform binaries with GoReleaser, publish to GitHub Releases, and sync to Terraform Registry. Version is injected into the provider during build for user agent.

```bash
# Show current version and next version options
make version-show
# Output:
# Current version: v4.3.3
# Next patch: 4.3.4
# Next minor: 4.4.0
# Next major: 5.0.0

# Bump patch version (4.3.3 → 4.3.4) and create tag
make version-patch

# Bump minor version (4.3.3 → 4.4.0) and create tag
make version-minor

# Bump major version (4.3.3 → 5.0.0) and create tag
make version-major

# Bump patch and trigger CI release in one step
make release-patch
# This will:
# 1. Create and push git tag v4.3.4
# 2. GitHub Actions triggers on tag
# 3. GoReleaser builds multi-platform binaries
# 4. Publishes to GitHub Releases
# 5. Terraform Registry automatically syncs

# Release workflow for minor version
make release-minor
# Same process for v4.4.0

# Note: Version is injected by GoReleaser during build
# meta.GetVersion() → provider.New() → client.UserAgent
```

--------------------------------

### Define schedule rotation active days - Terraform

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/escalation_level.md

Configures active days and time ranges for a schedule rotation. Each day specifies start and end times for on-call coverage.

```terraform
resource "rootly_schedule_rotation_active_day" "m1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "M"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
resource "rootly_schedule_rotation_active_day" "t1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "T"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
resource "rootly_schedule_rotation_active_day" "w1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "W"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
resource "rootly_schedule_rotation_active_day" "th1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "R"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
resource "rootly_schedule_rotation_active_day" "f1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "F"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
```

--------------------------------

### Terraform rootly_schedule_rotation Resource

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/schedule_rotation.md

This example demonstrates how to configure a rootly_schedule_rotation resource within Terraform. It defines a rotation named 'weekdays' associated with a specific schedule, sets active days, and assigns users.

```terraform
data "rootly_user" "john" {
  email = "demo@rootly.com"
}

data "rootly_user" "jane" {
  email = "demo1@rootly.com"
}

data "rootly_alert_urgency" "low" {
  name = "Low"
}

resource "rootly_team" "sre" {
  name     = "SREs On-Call"
  user_ids = [data.rootly_user.john.id, data.rootly_user.jane.id]
}

resource "rootly_schedule" "primary" {
  name              = "Primary On-Call Schedule"
  owner_user_id     = data.rootly_user.john.id
  all_time_coverage = false
}

resource "rootly_schedule_rotation" "weekdays" {
  schedule_id     = rootly_schedule.primary.id
  name            = "weekdays"
  active_all_week = false
  active_days = [
    "M",
    "T",
    "W",
    "R",
    "F",
  ]
  active_time_type = "custom"
  position         = 1
  schedule_rotationable_attributes = {
    handoff_time = "10:00"
  }
  schedule_rotationable_type = "ScheduleDailyRotation"
  time_zone                  = "America/Toronto"
}

# Define active days for the weekday rotation
# Monday
resource "rootly_schedule_rotation_active_day" "m1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "M"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
# Tuesday
resource "rootly_schedule_rotation_active_day" "t1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "T"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
# Wednesday
resource "rootly_schedule_rotation_active_day" "w1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "W"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
# Thursday
resource "rootly_schedule_rotation_active_day" "th1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "R"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}
# Friday
resource "rootly_schedule_rotation_active_day" "f1-weekday" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  day_name             = "F"
  active_time_attributes {
    start_time = "10:00"
    end_time   = "18:00"
  }
}

resource "rootly_schedule_rotation_user" "john" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  position             = 1
  user_id              = data.rootly_user.john.id
}

resource "rootly_schedule_rotation_user" "jane" {
  schedule_rotation_id = rootly_schedule_rotation.weekdays.id
  position             = 2
  user_id              = data.rootly_user.jane.id
}

```

--------------------------------

### Build Rootly Terraform Provider

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/README.md

Complete build command that generates code, compiles the provider, and regenerates documentation. Requires Terraform 0.14 or later. This is the main build command for the provider development workflow.

```bash
make build
```

--------------------------------

### Import rootly_workflow_task_create_go_to_meeting (Shell)

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_create_go_to_meeting.md

Demonstrates how to import an existing rootly_workflow_task_create_go_to_meeting resource using the Terraform import command.

```sh
terraform import rootly_workflow_task_create_go_to_meeting.primary a816421c-6ceb-481a-87c4-585e47451f24
```

--------------------------------

### Copy Provider to Local Registry

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/README.md

Copies the built provider binary to the local registry directory with the appropriate naming convention. The architecture label should match the target system.

```bash
# copy the provider
cp terraform-provider-rootly ~/.terraform.d/plugins/terraform.local/local/rootly/1.0.0/darwin_arm64/terraform-provider-rootly_v1.0.0
```

--------------------------------

### Run Acceptance Tests

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/README.md

Executes acceptance tests for the Rootly Terraform provider. These tests validate the provider's functionality against the actual Rootly API.

```bash
make testacc
```

--------------------------------

### Go Client Rate Limiting and Error Handling

Source: https://context7.com/rootlyhq/terraform-provider-rootly/llms.txt

Demonstrates configuring the Rootly API client in Go for automatic rate limiting retries on 429 errors using exponential backoff (1s to 5m, up to 8 attempts), respecting reset headers, and warning on low limits. Handles NotFound and Request errors explicitly. Includes bulk creation with manual delays to avoid overwhelming the API; requires the client package and API token.

```go
package main

import (
    "log"
    "time"

    "github.com/rootlyhq/terraform-provider-rootly/v2/client"
)

func main() {
    // Client configuration with rate limiting
    c, err := client.NewClient(
        "https://api.rootly.com",
        "your-api-token",
        "CustomApp/1.0.0",
    )
    if err != nil {
        log.Fatal(err)
    }

    // Client automatically:
    // - Retries on 429 (rate limit) errors
    // - Uses exponential backoff (1s min, 5m max)
    // - Respects X-RateLimit-Reset header
    // - Warns when rate limit approaches (< 10 remaining)
    // - Maximum 8 retry attempts

    // Handle NotFound errors
    service, err := c.GetService("non-existent-id")
    if err != nil {
        if notFoundErr, ok := err.(*client.NotFoundError); ok {
            log.Printf("Service not found: %v", notFoundErr)
            // Handle gracefully - maybe create new resource
        } else if reqErr, ok := err.(*client.RequestError); ok {
            log.Printf("Request failed with status %d: %s",
                reqErr.StatusCode, reqErr.Body)
        } else {
            log.Fatalf("Unexpected error: %v", err)
        }
    }

    // Bulk operations with automatic retry
    for i := 0; i < 100; i++ {
        newService := &client.Service{
            Name: fmt.Sprintf("service-%d", i),
        }

        _, err := c.CreateService(newService)
        if err != nil {
            log.Printf("Failed to create service %d: %v", i, err)
            // Client will have already retried
            continue
        }

        // Small delay to avoid overwhelming API
        time.Sleep(100 * time.Millisecond)
    }
}
```

--------------------------------

### Configure Rootly Provider with API Credentials - Terraform

Source: https://context7.com/rootlyhq/terraform-provider-rootly/llms.txt

Sets up the Rootly Terraform provider with API credentials. Authentication uses a bearer token from environment variables or direct configuration. Includes provider version specification.

```terraform
terraform {
  required_providers {
    rootly = {
      source  = "rootlyhq/rootly"
      version = "~> 4.3"
    }
  }
}

provider "rootly" {
  # api_token is sourced from ROOTLY_API_TOKEN environment variable
  # Optionally override the API host (defaults to https://api.rootly.com)
  # api_host = "https://api.rootly.com"
}
```

--------------------------------

### Run Unit Tests for Provider

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/README.md

Executes unit tests for the Rootly Terraform provider. Tests that cannot be code-generated should be added to the ignore-list in tools/generate.js and implemented manually.

```bash
make test
```

--------------------------------

### Create Local Plugin Directory

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/README.md

Creates the required directory structure for the local Terraform provider plugin. The architecture label (darwin_arm64) should be changed according to the target system.

```bash
# make the directory
mkdir -p ~/.terraform.d/plugins/terraform.local/local/rootly/1.0.0/darwin_arm64/
```

--------------------------------

### Import Rootly Workflow Task Get Alerts using Terraform Import Block

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_get_alerts.md

Defines an import block within Terraform configuration to import the rootly_workflow_task_get_alerts resource. Useful for automated imports in code repositories. The block specifies the target resource and its ID.

```terraform
import {
  to = rootly_workflow_task_get_alerts.primary
  id = "a816421c-6ceb-481a-87c4-585e47451f24"
}
```

--------------------------------

### Query Existing Services and Users - Terraform

Source: https://context7.com/rootlyhq/terraform-provider-rootly/llms.txt

Uses Terraform data sources to reference existing services, users, and severities in configurations, enabling dynamic resource creation based on existing data.

```terraform
data "rootly_service" "payment_service" {
  slug = "payment-service"
}

data "rootly_user" "john" {
  email = "john@acme.com"
}

data "rootly_severity" "critical" {
  name = "SEV0"
}

# Use data source outputs in resources
resource "rootly_workflow_incident" "page_for_payment" {
  name = "Page on-call for payment service incidents"
  trigger_params {
    triggers      = ["incident_created"]
    service_ids   = [data.rootly_service.payment_service.id]
    severity_ids  = [data.rootly_severity.critical.id]
  }
  enabled = true
}
```

--------------------------------

### Retrieve Rootly Service - Terraform

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/data-sources/service.md

This example demonstrates how to retrieve a Rootly service using the `rootly_service` data source. The `slug` attribute is used to identify the service to retrieve. The schema includes optional and read-only attributes for filtering and displaying service details.

```terraform
data "rootly_service" "my-service" {
  slug = "my-service"
}
```

--------------------------------

### Set Authentication Token and Initialize Terraform - Bash

Source: https://context7.com/rootlyhq/terraform-provider-rootly/llms.txt

Bash commands to set the Rootly API token as an environment variable and initialize Terraform for provider configuration.

```bash
# Set authentication token
export ROOTLY_API_TOKEN="your-api-token-here"

# Initialize Terraform
terraform init
terraform plan
terraform apply
```

--------------------------------

### Manage Slack Message Workflow Task - Terraform

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/resources/workflow_task_send_slack_message.md

Configures a workflow task to send Slack messages during incident response. Requires a parent workflow and supports various Slack channels, users, and formatting options. The example shows incident-triggered notification with channel targeting and customizable message text.

```HCL
resource "rootly_workflow_incident" "notify_slack_channels" {
  name        = "Notify teams on Slack about the incident"
  description = "Send a message to specific teams on Slack regarding the incident."
  trigger_params {
    triggers                  = ["incident_created"]
    incident_statuses         = ["started"]
    incident_condition_status = "IS"
  }
  enabled = true
}

resource "rootly_workflow_task_send_slack_message" "send_slack_message" {
  workflow_id     = rootly_workflow_incident.notify_slack_channels.id
  skip_on_failure = false
  enabled         = true
  task_params {
    name = "Notify team about incident"
    channels {
      id   = "{{ incident.slack_channel_id }}"
      name = "{{ incident.slack_channel_id }}"
    }
    text = "Heads up - wanted to let your team know we have an active incident."
  }
}
```

```Shell
# Import using terraform import command:
terraform import rootly_workflow_task_send_slack_message.send_slack_message 00000000-0000-0000-0000-000000000000

# Generate configuration from import:
terraform plan -generate-config-out=generated.tf
```

```HCL
import {
  to = rootly_workflow_task_send_slack_message.primary
  id = "a816421c-6ceb-481a-87c4-585e47451f24"
}
```

--------------------------------

### Find Alert Route by Name - Terraform

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/docs/data-sources/alert_route.md

This Terraform code snippet retrieves an alert route named 'Production Alerts' using the rootly_alert_route data source. It requires advanced alert routing access. The example also includes an output to expose the alert route ID for use in other resources.

```terraform
# Find an alert route by name
data "rootly_alert_route" "example" {
  name = "Production Alerts"
}

# Use the alert route ID in other resources
output "alert_route_id" {
  value = data.rootly_alert_route.example.id
}
```

--------------------------------

### Release Management Commands

Source: https://github.com/rootlyhq/terraform-provider-rootly/blob/master/README.md

Commands for releasing new versions of the provider. These automatically push git tags which trigger CI/GoReleaser workflows for building and publishing releases to GitHub and Terraform Registry.

```bash
make release-patch     # Bump patch version + push tag (triggers CI release)
make release-minor     # Bump minor version + push tag (triggers CI release)
make release-major     # Bump major version + push tag (triggers CI release)
```