Skip to main content
Version: 1.0

Webhooks

KubeOpera has two genuinely different things that could be called a "webhook," and it's worth being precise about which one you mean, because they run in opposite directions. There is no self-service webhook subscription system (no "register a URL to be notified of any platform event" API) — the platform's actual webhook surface is narrower and more specific than that.

Inbound: your repository notifying KubeOpera​

This is the more common case: a tenant's own Git repository is configured to push a webhook to KubeOpera whenever code is pushed, and KubeOpera uses that to trigger a CI run or a Kaniko build automatically. This is not something you subscribe to through an API call — it's configured the normal way, in your repository host's own webhook settings, pointed at a URL KubeOpera gives you when you register a pipeline or a build config.

  • CI pipeline runs — configuring a pipeline in the Pipelines dashboard gives you a webhook URL ({provider} is github or gitlab) to add to your repository's settings. A push is what starts tracking a real CI run.
  • Automatic image builds — registering a Build Config for auto-rebuild-on-push, documented on the Build Service page, works the same way: KubeOpera gives you a URL, your repository's own webhook settings point at it.

Both accept the provider's standard webhook payload shape and, where a shared secret is configured, verify it using that provider's own signature scheme — nothing KubeOpera-specific to implement on your end.

Outbound: KubeOpera notifying you about an incident​

The one genuine "KubeOpera calls a URL you control" mechanism today is narrower than a general event bus: incident-manager can be configured with a single webhook URL (alongside its Slack/email/PagerDuty notification channels) that receives a POST for exactly three event types — incident.created, incident.updated, and incident.resolved. The request body carries the incident's ID, cluster, title, severity, status, category, namespace, affected service, message, and timestamp as plain JSON, and — when a shared secret is configured — an X-Webhook-Secret header carrying it, for you to verify on receipt.

{
  "event_type": "incident.created",
  "incident_id": "inc-8f2a1c",
  "cluster_id": "kubeopera-prod",
  "title": "Elevated error rate on payments-api",
  "severity": "critical",
  "status": "open",
  "category": "availability",
  "namespace": "payments",
  "affected_service": "payments-api",
  "message": "Error rate exceeded 5% for 5 consecutive minutes",
  "occurred_at": "2026-09-09T14:02:31Z"
}

There's no per-event subscription filtering — a configured URL receives all three event types — and no other resource in the platform (an app deploying, a pipeline run finishing, and so on) currently has an equivalent outbound webhook. If you need to react to one of those events today, the MCP Server tools or polling the relevant REST endpoint are the available options.

Next Steps​