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.

Deploy webhooks require an active GCP connector. Set up your GCP connector first.

How it works

You generate a webhook token for your GCP connector
You add a one-line curl call to your CI/CD pipeline (GitHub Actions, CircleCI, Cloud Build, etc.)
After each deploy, your pipeline fires the webhook
Flare waits 60 minutes for post-deploy activity to accumulate
Flare fetches audit logs from before the deploy and after, runs anomaly analysis on both windows, and compares them
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

Go to Connectors
Select your connected GCP connector
In the Deploy webhook section, click Generate webhook token
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.

# 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

# 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 }}"}'

# 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}\"}"

# 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"}'

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"}'

The commit-sha and branch inputs are automatically populated from the GitHub context. See all available inputs and outputs on the GitHub Marketplace listing.

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:

{
  "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.

Getting Started

Connectors

Analyses

Automation

Support

Deploy Webhooks

Deploy Webhooks

How it works

What Flare looks for

Setting up

1. Generate a webhook token

2. Add to your CI/CD pipeline

Action outputs

Request body (optional)

Response

Pre-deploy baseline

Debouncing

Viewing results

Revoking a token

Combining with scheduled runs

​Deploy Webhooks

​How it works

​What Flare looks for

​Setting up

​1. Generate a webhook token

​2. Add to your CI/CD pipeline

​Action outputs

​Request body (optional)

​Response

​Pre-deploy baseline

​Debouncing

​Viewing results

​Revoking a token

​Combining with scheduled runs

Deploy Webhooks

How it works

What Flare looks for

Setting up

1. Generate a webhook token

2. Add to your CI/CD pipeline

Action outputs

Request body (optional)

Response

Pre-deploy baseline

Debouncing

Viewing results

Revoking a token

Combining with scheduled runs