Incident.io WorkflowRuns V2 API

openapi: 3.2.0
info:
  description: 'This is the API reference for incident.io. It documents available API endpoints, provides examples of how to use it, and

    instructions around things like authentication and error handling. The API is hosted at:


    - https://api.incident.io/


    And you will need to create an API key via your incident.io

    dashboard to make requests. # Making requests


    Here are the key concepts required to make requests to the incident.io API. ## Authentication


    For all requests made to the incident.io API, you''ll need an API key. To create an API key, head to the incident dashboard and visit API

    keys. When you create the key, you''ll be able to choose what actions it

    can take for your account: choose carefully, as those roles can only be set

    when you first create the key. We''ll only show you the token once, so make sure

    you store it somewhere safe. API keys are global to your incident.io account, and can be managed by anyone

    who has the right permissions. We display the user that created the API key,

    and the API key will remain valid if that user becomes deactivated. Once you have the key, you should make requests to the API that set the

    `Authorization` request header using a "Bearer" authentication scheme:


    ```

    Authorization: Bearer

    ```


    ## Rate Limits


    The incident.io API enforces rate limits to ensure consistent performance for all users. The default rate limit is 1200 requests/minute per API key. This limit applies to most endpoints across the API. Limits are token buckets that refill continuously rather than resetting on a fixed window boundary. The default

    bucket holds 1200 requests and refills at 20 per second, so you can burst up to the full bucket and then sustain

    20 requests/second indefinitely. There is no boundary at which your quota resets to full in one step. Some endpoints have lower rate limits, particularly those that interact with external third-party systems that impose

    their own limitations. These specific limits vary by endpoint. ### Rate limit headers


    Responses to requests authenticated with an API key carry your current allowance, so you can pace yourself rather

    than waiting to be throttled:


    ```

    X-RateLimit-Limit: 60, 1200;window=60, 60;window=60

    X-RateLimit-Remaining: 59

    X-RateLimit-Used: 1

    X-RateLimit-Reset: 1785173199

    ```


    | Header | Meaning |

    | --- | --- |

    | `X-RateLimit-Limit` | The quota that binds this request, followed by every limit that applied and the window it applies over |

    | `X-RateLimit-Remaining` | Requests you can make right now against the binding limit |

    | `X-RateLimit-Used` | Requests you have spent against it |

    | `X-RateLimit-Reset` | Unix timestamp (seconds) at which that limit will be back to full |


    More than one limit can apply to a request: your API key''s overall limit, and for some endpoints a lower limit of

    their own. `X-RateLimit-Limit` lists all of them, each with its window, so `1200;window=60` means 1200 requests per

    minute. Because our limits refill continuously rather than resetting on a boundary, that window is what tells you

    the rate you can sustain: 1200 per 60 seconds is 20 requests/second indefinitely. `Remaining`, `Used` and `Reset` describe whichever limit has the least allowance left, since that is the one you

    will hit first. `X-RateLimit-Remaining` may lag by a small number of requests under high concurrency, and can move by more than the

    requests you made, because limits scoped to your whole organisation are shared with your other API keys. Headers are omitted rather than guessed if we cannot determine your allowance for a request. ### Exceeding a rate limit


    When you exceed a rate limit the API responds with `429 Too Many Requests` and a `Retry-After` header giving the

    number of seconds to wait:


    ```

    X-RateLimit-Limit: 1200, 1200;window=60

    X-RateLimit-Remaining: 0

    X-RateLimit-Used: 1200

    X-RateLimit-Reset: 1785173199

    Retry-After: 1

    ```


    Prefer `Retry-After` over `X-RateLimit-Reset` when deciding how long to back off.'
  title: incident.io WorkflowRuns V2 API
  version: 1.0.0
servers:
- url: https://api.incident.io
security:
- BearerAuth: []
tags:


# --- truncated at 32 KB (50 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/incident-io/refs/heads/main/openapi/incident-io-workflowruns-v2-api-openapi.yml