Incident.io Webhooks API

Webhooks can be used to receive notifications when certain events occur in incident.io. This might be useful for annotating graphs in a monitoring tool with incidents, or keeping track of follow-ups in another system. Our webhooks are powered by Svix. ## Getting started with webhooks To start using webhooks, you’ll need to create a webhook endpoint. You can do this in the same way that you’d create any other endpoint in your application. If you’d like to play around with our webhooks, we’d recommend using Svix play which allows you to set up an endpoint and inspect the payloads via their web interface. There are also other services (e.g. ngrok) which have great debugging tools to help getting started with webhooks. Once you have a webhook endpoint set up, you can head to Settings > Webhooks to configure your endpoint. In here you'll be able to choose which types of events you'd like to recieve, send test events, see recent event deliveries, and retry any failed events. ## Status codes, errors and retries When processing webhooks, please return a 2xx status code (e.g. `200 OK` or `204 No Content`). If the endpoint returns a non-2xx status code, we’ll try to resend the event with a backoff over the next 24 hours. If attempts to a specific endpoint repeatedly fail over a 5 day period, we’ll mark the endpoint as disabled and notify you via email. If you do miss some messages (e.g. due to unexpected downtime), Svix offer a number of options for [replaying messages](https://docs.svix.com/receiving/using-app-portal/replaying-messages) which you can access via Settings > Webhooks. ## Verifying webhooks It’s important to know whether a webhook has come from incident.io, or a third party that might be trying to exploit a vulnerability. To avoid this, we send a `signature` in the header of our webhooks, which you can verify using the `Signing secret` from the webhook endpoint settings page. The webhooks we send will have three headers that you’ll want to look at: ```json { "webhook-id": "123", "webhook-timestamp": 1676033031, "webhook-signature": "v1,g0hM9SsE+OTPJTGt/tmIKtSyZlE3uFJELVlNIOLJ1OE=" } ``` These are signed using a HMAC signature in the following format: ``` $WEBHOOK_ID.$WEBHOOK_TIMESTAMP.$REQUEST_BODY ``` You can verify the signature either using the Svix client libraries, or manually by following these instructions. ## Keeping another system in-line with incident.io A common use-case for webhooks is to keep another system up-to-date with everything that’s happening in incident.io. As we deliver webhooks individually over HTTPS, we cannot guarantee that they’ll be delivered in the correct order. That means that, to keep the other system up-to-date, we’d recommend that you build an application which: - Receives a webhook about INC-123 - Makes a request to our public API to get the latest state of INC-123 - Save that state to your system This means you aren’t relying on the order in which you receive webhooks to make sure your system remains up-to-date. ## Webhooks on private incidents In general, we try to send webhooks with all the relevant information in the payload (e.g. the name, summary, status etc.). However, private incidents are the exception. For private incidents, we only send the ID of the resource that’s been changed. If your integration needs to access the full data, you’ll need to create an API Key that can view private incidents. You can then use that key to get the details about the specific incident or follow-up. This is to make sure we don’t leak information about private incidents to a system that shouldn’t have access to them.

Work with this as data

Every API here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for apis

7 MCP tools reach this
  • find_apisBrowse and filter every API in the catalog.
  • get_api_artifactsOne API's artifacts, grouped by type.
  • get_openapiThe primary OpenAPI for this API.
  • find_similar_apisAPIs that look like this one.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This API
curl "https://apis.io/api/v1/apis/incident-io:incident-io-webhooks-api"
All apis
curl "https://apis.io/api/v1/apis?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.

OpenAPI Specification

incident-io-webhooks-api-openapi.yml Raw ↑
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 Webhooks API
  version: 1.0.0
servers:
- url: https://api.incident.io
security:
- BearerAuth: []
tags:


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