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

# Deploy Webhooks

> Automatically compare pre-deploy and post-deploy audit logs after every deployment

# Deploy Webhooks

Deploy webhooks give you an automatic security review after every deployment. When your CI/CD pipeline fires the webhook, Flare compares audit logs from before and after the deploy to catch IAM changes, new service accounts, permission escalations, and access pattern shifts introduced by the deployment.

<Note>
  Deploy webhooks require an active GCP connector. Set up your [GCP connector](/connectors/gcp) first.
</Note>

## How it works

1. You generate a webhook token for your GCP connector
2. You add a one-line `curl` call to your CI/CD pipeline (GitHub Actions, CircleCI, Cloud Build, etc.)
3. After each deploy, your pipeline fires the webhook
4. Flare waits 60 minutes for post-deploy activity to accumulate
5. Flare fetches audit logs from **before** the deploy and **after**, runs anomaly analysis on both windows, and compares them
6. The comparison analysis appears in your Analyses history with a "Post-deploy" badge

### What Flare looks for

The comparison focuses on what **changed** between the two windows:

| Change type                | Example                                                                   |
| -------------------------- | ------------------------------------------------------------------------- |
| **New principals**         | A service account that only appears after the deploy                      |
| **IAM mutations**          | Role bindings or policy changes introduced by the deploy                  |
| **Permission escalations** | Actions requiring higher privileges than pre-deploy activity              |
| **New IP addresses**       | Source IPs that appear only in the post-deploy window                     |
| **Frequency shifts**       | Operations that existed before but now occur at different rates           |
| **Disappeared patterns**   | Regular activity that stops after the deploy (may indicate broken access) |

## Setting up

### 1. Generate a webhook token

1. Go to **Connectors**
2. Select your connected GCP connector
3. In the **Deploy webhook** section, click **Generate webhook token**
4. Copy the token immediately -- it is only shown once

### 2. Add to your CI/CD pipeline

Add a webhook call as a post-deploy step. The only required piece is the `Authorization` header with your token.

<CodeGroup>
  ```yaml GitHub Actions (recommended) theme={null}
  # Add as the last step in your deploy job
  - name: Flare post-deploy security review
    uses: tryflare-ai/deploy-webhook@v1
    with:
      token: ${{ secrets.FLARE_WEBHOOK_TOKEN }}
      environment: production  # optional
  ```

  ```yaml GitHub Actions (curl) theme={null}
  # Alternative: use curl directly
  - name: Notify Flare
    if: success()
    run: |
      curl -X POST https://www.tryflare.ai/api/webhooks/deploy \
        -H "Authorization: Bearer ${{ secrets.FLARE_WEBHOOK_TOKEN }}" \
        -H "Content-Type: application/json" \
        -d '{"commit_sha": "${{ github.sha }}", "branch": "${{ github.ref_name }}"}'
  ```

  ```yaml CircleCI theme={null}
  # Add as the last step in your deploy job
  - run:
      name: Notify Flare
      command: |
        curl -X POST https://www.tryflare.ai/api/webhooks/deploy \
          -H "Authorization: Bearer ${FLARE_WEBHOOK_TOKEN}" \
          -H "Content-Type: application/json" \
          -d "{\"commit_sha\": \"${CIRCLE_SHA1}\", \"branch\": \"${CIRCLE_BRANCH}\"}"
  ```

  ```yaml Google Cloud Build theme={null}
  # Add as the last step in cloudbuild.yaml
  - name: 'gcr.io/cloud-builders/curl'
    args:
      - '-X'
      - 'POST'
      - 'https://www.tryflare.ai/api/webhooks/deploy'
      - '-H'
      - 'Authorization: Bearer $$FLARE_WEBHOOK_TOKEN'
      - '-H'
      - 'Content-Type: application/json'
      - '-d'
      - '{"commit_sha": "$COMMIT_SHA", "branch": "$BRANCH_NAME"}'
  ```

  ```bash Generic (curl) theme={null}
  curl -X POST https://www.tryflare.ai/api/webhooks/deploy \
    -H "Authorization: Bearer YOUR_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"commit_sha": "abc1234", "branch": "main"}'
  ```
</CodeGroup>

The `commit-sha` and `branch` inputs are automatically populated from the GitHub context. See all available inputs and outputs on the [GitHub Marketplace listing](https://github.com/marketplace/actions/flare-deploy-webhook).

#### Action outputs

The action exposes two outputs you can use in subsequent workflow steps:

| Output        | Description                                              |
| ------------- | -------------------------------------------------------- |
| `analysis-at` | ISO timestamp for when the post-deploy analysis will run |
| `queued`      | `true` if the analysis was successfully queued           |

### Request body (optional)

The request body is optional. If provided, the metadata is stored with the analysis for reference.

| Field         | Type   | Description                                |
| ------------- | ------ | ------------------------------------------ |
| `commit_sha`  | string | Git commit SHA that was deployed           |
| `branch`      | string | Branch that was deployed                   |
| `environment` | string | Deployment environment (e.g. "production") |

### Response

A successful webhook returns `202 Accepted`:

```json theme={null}
{
  "queued": true,
  "analysis_at": "2026-05-30T15:30:00.000Z",
  "connector_name": "GCP Production"
}
```

## Pre-deploy baseline

Flare needs a "before" snapshot to compare against. The pre-deploy lookback window matches your connector's scheduled run frequency:

| Your schedule   | Pre-deploy window              |
| --------------- | ------------------------------ |
| Every hour      | 1 hour before deploy           |
| Every 6 hours   | 6 hours before deploy          |
| Every 24 hours  | 24 hours before deploy         |
| No schedule set | 1 hour before deploy (default) |

This makes the comparison consistent with what you already consider "normal activity" for that connector.

## Debouncing

If your CI/CD fires the webhook multiple times in quick succession (e.g., multiple merges, failed deploys, retries), Flare debounces automatically. Only the **most recent** deploy gets analyzed. Earlier pending deploys are overwritten.

This means you won't waste analysis credits on intermediate deployment states -- Flare always analyzes the final state.

## Viewing results

Deploy analyses appear in your **Analyses** history with a green **Post-deploy** badge. The analysis name includes the commit SHA when provided (e.g., "Post-deploy abc1234 - GCP Production").

The anomaly results include a `changeType` for each finding:

* **New** -- this value appeared only after the deploy
* **Frequency shift** -- this value existed before but at a different rate
* **Disappeared** -- this value was present before but absent after the deploy

## Revoking a token

From the Connectors page, click **Revoke token** in the Deploy webhook section. This immediately invalidates the token -- all CI/CD pipelines using it will receive `401 Unauthorized`. Any pending deploy analyses for that connector are also cancelled.

Generate a new token if you need to re-enable the webhook.

## Combining with scheduled runs

Deploy webhooks and scheduled runs work independently on the same connector. You can (and should) use both:

* **Scheduled runs** catch anomalies during normal operations
* **Deploy webhooks** catch anomalies specifically introduced by deployments

Both appear in the same Analyses history. The badges ("Scheduled" and "Post-deploy") help you distinguish them.