DocsBook a demo

Platform

Platform overviewArchitectureWorkflow orchestrationGitOps configurationGovernance and AAAAI and MCPKnowledge and contextRuntime and executionEvidence and monitoring

Use cases

All use casesProduction incidentRelease preparationHotfix to productionSecurity scan triage
Why NopsAIIntegrationsSecurity

Resources

All resourcesAI agent governanceMCP governanceMCP securitySelf-hosted platforms
PricingGitHub

Company

How a run worksAboutContactBook a demo

Git webhook sources

Managed ingress for GitLab, Bitbucket, Gitea, and generic providers.

How-toAdministratorDeveloper

Key points

  • Each source owns its own signing secret and receives deliveries at POST /v1/git/webhooks/{sourceID}.
  • Deliveries are normalized into the same event model that GitHub App events use, so trigger manifests stay provider-neutral.
  • Recent deliveries are visible for diagnosis at GET /v1/git-webhook-sources/{sourceID}/deliveries.
  • A trigger manifest for a non-GitHub provider must reference the source by ID.

Before you start

Provider
A GitLab, Bitbucket, Gitea, or generic provider that can send webhooks
Reachable ingress
The webhook endpoint reachable from the provider; nothing else about the install needs to be exposed
Access
Permission to create Git webhook sources and the trigger that consumes them

Steps

  1. 01

    Create the source

    A source owns its provider kind, its signing secret, and the repository allowlist that bounds what it may start runs for.

    Create a sourcebash
    curl -sX POST "$NOPSAI_URL/v1/git-webhook-sources" \
  -H "Authorization: Bearer $NOPSAI_TOKEN" \
  -H "Content-Type: application/json" \
  --data @source.json | jq -r .id
    Replace before running
    • source.json names the provider kind, the signing secret reference, and the allowed owner/repository patterns.
    Expected result
    • A source ID. Deliveries for this source arrive at POST /v1/git/webhooks/{sourceID}.
  2. 02

    Point the provider at it

    Configure the webhook in the provider with that URL and the same signing secret. Every delivery is signature-verified before it is accepted.

    Verify
    • The provider reports a successful delivery, and the source lists it.
  3. 03

    Read the deliveries

    Delivery history is the first place to look when a push produced no run: it separates "never arrived" from "arrived and was rejected".

    List recent deliveriesbash
    curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/git-webhook-sources/$SOURCE_ID/deliveries" | jq
    Verify
    • The delivery appears with its verification result and the event it normalised to.
  4. 04

    Bind a trigger to the source

    A trigger manifest for a non-GitHub provider must reference the source by ID. The event model is already normalised, so the manifest stays provider-neutral.

    Verify
    • A push matching the trigger rules produces a run.

How it works

The webhook endpoint is public by necessity — the provider calls it — but every delivery is signature-verified against the source secret before it is accepted.

A repository allowlist limits which repositories a source may start runs for, so one shared source cannot be used to trigger unrelated pipelines.

Implementation evidence

  • doc/git-webhook-sources.md

    Provider configuration, security, payload normalization, and operations.

  • services/nopsai/git_webhook_sources_schema.go

    Source schema and delivery handling.