> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scrubbe.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ingest Alerts from Prometheus, Datadog, and More

> Route alerts from Prometheus, Datadog, PagerDuty, Kubernetes, GitHub Actions, GitLab Pipelines, or any custom tool into Scrubbe using webhook ingestion.

Scrubbe's ingestion endpoints accept inbound webhook payloads from your monitoring, CI, and on-call platforms and convert them into incident signals automatically. Each endpoint understands the native payload format of its source — you configure the webhook URL in the external tool and Scrubbe handles the rest. All ingestion endpoints authenticate using an `X-API-Key` header rather than a session-based Bearer token, so they work cleanly in server-to-server and automated pipeline contexts.

<Warning>
  Ingestion endpoints do **not** accept `Authorization: Bearer` tokens. Every request must include your Scrubbe API key in the `X-API-Key` request header. Requests without a valid key are rejected with `401 Unauthorized`.
</Warning>

## Base URL and authentication

All ingestion endpoints share the base path `/api/v1/ingestion`. Include your API key on every request:

```http theme={null}
POST /api/v1/ingestion/<source>
X-API-Key: <your-api-key>
Content-Type: application/json
```

You can find or generate your API key in **Settings → API Keys** inside the Scrubbe dashboard.

## Supported sources

<CardGroup cols={2}>
  <Card title="Prometheus Alertmanager" icon="activity">
    `POST /api/v1/ingestion/prometheus`
  </Card>

  <Card title="Datadog" icon="bar-chart-2">
    `POST /api/v1/ingestion/datadog`
  </Card>

  <Card title="PagerDuty" icon="bell">
    `POST /api/v1/ingestion/pagerduty`
  </Card>

  <Card title="Kubernetes" icon="box">
    `POST /api/v1/ingestion/kubernetes`
  </Card>

  <Card title="GitHub Actions" icon="github">
    `POST /api/v1/ingestion/github`
  </Card>

  <Card title="GitLab Pipelines" icon="gitlab">
    `POST /api/v1/ingestion/gitlab`
  </Card>

  <Card title="Generic webhook" icon="webhook">
    `POST /api/v1/ingestion/webhook`
  </Card>
</CardGroup>

***

## Prometheus Alertmanager

Point an Alertmanager webhook receiver at Scrubbe to convert firing alerts into incident signals. Scrubbe parses the standard Alertmanager `alerts` array and creates one incident per unique alert name and label set.

```yaml theme={null}
# alertmanager.yml
receivers:
  - name: scrubbe
    webhook_configs:
      - url: https://your-scrubbe-instance/api/v1/ingestion/prometheus
        http_config:
          headers:
            X-API-Key: <your-api-key>
```

<Tip>
  Set `send_resolved: true` in your Alertmanager receiver config so that Scrubbe automatically resolves incidents when alerts clear.
</Tip>

***

## Datadog

Add a webhook notification channel in Datadog and point it at the Scrubbe ingestion endpoint. Scrubbe processes the standard Datadog alert webhook payload and maps monitor states to incident severities.

<Steps>
  <Step title="Create a webhook integration in Datadog">
    In Datadog, go to **Integrations → Webhooks** and click **New**.
  </Step>

  <Step title="Configure the webhook">
    Set the **URL** to `https://your-scrubbe-instance/api/v1/ingestion/datadog` and add a custom header:

    | Header      | Value                |
    | ----------- | -------------------- |
    | `X-API-Key` | Your Scrubbe API key |
  </Step>

  <Step title="Add the webhook to a monitor">
    In any Datadog monitor's **Notify your team** section, add `@webhook-scrubbe` to route alerts to Scrubbe.
  </Step>
</Steps>

***

## PagerDuty

Scrubbe accepts PagerDuty V2 webhook payloads. Forward incident events from PagerDuty to Scrubbe to correlate on-call alerts with your Scrubbe incident tickets.

<Steps>
  <Step title="Add a webhook subscription in PagerDuty">
    In PagerDuty, open the service you want to monitor and go to **Integrations → Add a webhook**.
  </Step>

  <Step title="Set the endpoint URL">
    Enter `https://your-scrubbe-instance/api/v1/ingestion/pagerduty` as the endpoint URL. PagerDuty does not support custom request headers natively, so append your API key as a query parameter:

    ```
    https://your-scrubbe-instance/api/v1/ingestion/pagerduty?apiKey=<your-api-key>
    ```
  </Step>

  <Step title="Select event types">
    Subscribe to at least **incident.triggered** and **incident.resolved** to keep Scrubbe in sync with your PagerDuty incident state.
  </Step>
</Steps>

***

## Kubernetes

Send pod crash, OOMKill, and restart-loop events from your Kubernetes clusters to Scrubbe. You can use a tool such as [Botkube](https://botkube.io) or a custom controller to forward Kubernetes events as webhook payloads.

```http theme={null}
POST /api/v1/ingestion/kubernetes
X-API-Key: <your-api-key>
Content-Type: application/json

{
  "reason": "OOMKilling",
  "message": "Memory limit exceeded, killed container api-server",
  "involvedObject": {
    "kind": "Pod",
    "name": "api-server-7d6b9f-xkzpq",
    "namespace": "production"
  },
  "firstTimestamp": "2026-05-22T10:14:00Z"
}
```

***

## GitHub Actions

Scrubbe ingests `workflow_run` and `deployment_status` webhook events from GitHub. Configure this at the repository or organization level in GitHub.

<Steps>
  <Step title="Add a webhook in GitHub">
    Go to your repository (or organization) **Settings → Webhooks → Add webhook**.
  </Step>

  <Step title="Configure the webhook">
    * **Payload URL:** `https://your-scrubbe-instance/api/v1/ingestion/github`
    * **Content type:** `application/json`
    * **Secret:** Your Scrubbe API key
  </Step>

  <Step title="Select events">
    Choose **Let me select individual events** and enable **Workflow runs** and **Deployment statuses**.
  </Step>
</Steps>

***

## GitLab Pipelines

Scrubbe ingests GitLab pipeline webhook events for failed or blocked jobs. Configure the webhook inside your GitLab project settings.

<Steps>
  <Step title="Open webhook settings">
    In your GitLab project, go to **Settings → Webhooks**.
  </Step>

  <Step title="Configure the webhook">
    * **URL:** `https://your-scrubbe-instance/api/v1/ingestion/gitlab`
    * **Secret token:** Your Scrubbe API key
    * **Trigger:** Enable **Pipeline events** and **Deployment events**
  </Step>

  <Step title="Save and test">
    Click **Add webhook**, then use the **Test** button to send a sample payload and confirm Scrubbe receives it.
  </Step>
</Steps>

***

## Generic webhook

Use the generic ingestion endpoint to send events from any internal system or custom monitoring tool that does not have a dedicated Scrubbe integration. Send a payload that conforms to the Scrubbe canonical format:

```http theme={null}
POST /api/v1/ingestion/webhook
X-API-Key: <your-api-key>
Content-Type: application/json

{
  "title": "High error rate on checkout service",
  "severity": "CRITICAL",
  "source": "my-custom-monitor",
  "service": "checkout",
  "environment": "production",
  "timestamp": "2026-05-22T10:14:00Z",
  "metadata": {
    "errorRate": "12.4%",
    "threshold": "5%"
  }
}
```

| Field         | Type   | Required | Description                                               |
| ------------- | ------ | -------- | --------------------------------------------------------- |
| `title`       | string | Yes      | Short description of the alert or event.                  |
| `severity`    | string | Yes      | One of `INFO`, `WARNING`, `ERROR`, `CRITICAL`.            |
| `source`      | string | Yes      | Identifier for the system sending the event.              |
| `service`     | string | No       | The service or component affected.                        |
| `environment` | string | No       | The deployment environment (e.g., `production`).          |
| `timestamp`   | string | No       | ISO 8601 timestamp of when the event occurred.            |
| `metadata`    | object | No       | Any additional key-value pairs to attach to the incident. |

<Note>
  Scrubbe deduplicates ingestion events using a combination of `source`, `service`, and `environment`. Repeated alerts for the same combination update the existing open incident rather than creating new ones.
</Note>