Harness Events

generated: '2026-09-12'
method: searched
source: >-
  https://developer.harness.io/harness-platform/use-harness-platform/notifications-alerts-and-banners/notifications/configure-notifications.md,
  https://developer.harness.io/harness-platform/use-harness-platform/triggers/triggers-reference,
  https://github.com/harness/harness-schema/tree/main/cdevents,
  and the webhook management operations in openapi/_original/harness-apis-openapi.yaml
provider: Harness
providerId: harness
type: Webhooks
asyncapi_published: false
asyncapi_note: >-
  Harness publishes NO AsyncAPI document. The event surface is real and substantial but it
  is described in prose docs, in a CDEvents sample set, and in REST management operations —
  never as an event contract. This is the single largest machine-readable gap in an
  otherwise very well documented platform: an agent can discover every REST operation from
  the OpenAPI, but must read documentation to learn which events exist.
description: >-
  Harness has three distinct event surfaces: OUTBOUND notifications it POSTs to your
  endpoint when pipeline and stage events fire; INBOUND webhook triggers it receives from
  Git providers and custom callers to start pipelines; and CDEvents it emits in the CD
  Foundation's standard envelope.
surfaces:
  outbound_notifications:
    direction: outbound
    docs: https://developer.harness.io/harness-platform/use-harness-platform/notifications-alerts-and-banners/notifications/configure-notifications
    transport: HTTP POST with a JSON body containing the properties of the triggered event
    url_templating: >-
      The target URL is composed with Harness expressions evaluated in the context of the
      event, e.g. https://example.com/notify?execution=<+pipeline.executionId>. Stage-scoped
      expressions are not valid on pipeline-level events.
    channels: [Slack, Microsoft Teams, Email, Webhook, PagerDuty, Datadog]
    scopes: [pipeline, stage]
    templating: Custom notification templates can shape the payload per event.
    events:
      - {id: pipeline_start, name: Pipeline Start, scope: pipeline}
      - {id: pipeline_end, name: Pipeline End, scope: pipeline}
      - {id: pipeline_success, name: Pipeline Success, scope: pipeline}
      - {id: pipeline_failed, name: Pipeline Failed, scope: pipeline}
      - {id: pipeline_paused, name: Pipeline Paused, scope: pipeline}
      - id: waiting_for_user_action
        name: Waiting for User Action
        scope: pipeline
        note: >-
          Fires whenever the pipeline pauses for human input — an Approval step, Manual
          Intervention, or runtime execution input. This is the event an agent-driven
          workflow must subscribe to in order to know it is blocked on a human.
      - {id: stage_events, name: Stage-scoped equivalents, scope: stage, note: Selected per named stage.}
    payload_schema:
      published: false
      note: >-
        The docs state the POST carries "a JSON object containing the properties of the
        triggered event" but do not publish that object's schema. No JSON Schema, no
        AsyncAPI, no example payload reference was found.
  inbound_triggers:
    direction: inbound
    docs: https://developer.harness.io/harness-platform/use-harness-platform/triggers/triggers-reference
    description: >-
      Harness receives webhooks to start pipelines. Three flavours are documented — Git
      provider event triggers (GitHub, GitLab, Bitbucket, Azure Repos), custom triggers
      invoked with cURL, and EventRelay generic/Slack webhook triggers.
    kinds:
      - {id: git, name: Git event triggers, docs: https://developer.harness.io/harness-platform/use-harness-platform/triggers/triggering-pipelines}
      - {id: custom, name: Custom triggers, docs: https://developer.harness.io/harness-platform/use-harness-platform/triggers/trigger-deployments-using-custom-triggers}
      - {id: eventrelay-generic, name: EventRelay generic webhook triggers, docs: https://developer.harness.io/harness-platform/use-harness-platform/triggers/trigger-pipelines-using-generic-events}
      - {id: eventrelay-slack, name: EventRelay Slack webhook triggers, docs: https://developer.harness.io/harness-platform/use-harness-platform/triggers/trigger-pipelines-using-slack-events}
    selective_execution: Triggers can execute a subset of pipeline stages.
  cdevents:
    direction: outbound
    standard: CDEvents (CD Foundation)
    spec_version: 0.5.0-draft
    source: https://github.com/harness/harness-schema/tree/main/cdevents
    saved: json-schema/harness-cdevents-*.json
    event_types:
      - dev.cdevents.build.started
      - dev.cdevents.pipelinerun.started
      - dev.cdevents.pipelinerun.finished.0.3.0-draft (success)
      - dev.cdevents.pipelinerun.finished.0.3.0-draft (failure)
    note: >-
      This is the one part of the Harness event surface that IS standards-described. The
      envelope carries context.{version,id,chainId,source,type,timestamp} and
      subject.{id,source,type,content} with an app.harness.io source URI.
management_api:
  description: >-
    Webhooks are first-class managed resources in the REST contract — an agent can create
    and list them, it just cannot discover their payloads.
  operations:
    - {operationId: create-account-webhooks, path: /v1/webhooks, method: POST, scope: account}
    - {operationId: list-account-webhooks, path: /v1/webhooks/list, method: POST, scope: account}
    - {operationId: get-account-webhook, path: '/v1/webhooks/{webhook}', method: GET, scope: account}
    - {operationId: update-account-webhook, path: '/v1/webhooks/{webhook}', method: PUT, scope: account}
    - {operationId: delete-account-webhook, path: '/v1/webhooks/{webhook}', method: DELETE, scope: account}
    - {operationId: create-org-webhooks, path: '/v1/orgs/{org}/webhooks', method: POST, scope: organization}
    - {operationId: create-project-webhooks, path: '/v1/orgs/{org}/projects/{project}/webhooks', method: POST, scope: project}
    - {operationId: create-gitx-webhook, path: /v1/gitx-webhooks, method: POST, scope: account, note: Git Experience bidirectional sync webhooks}
    - {operationId: list-gitx-webhook-events, path: /v1/gitx-webhook-events, method: GET, note: Webhook event history for troubleshooting Git sync}
  total_webhook_operations: 68
  observability: >-
    Harness ships a Webhooks page with event history, per-repository sync health and
    webhook coverage reporting
    (https://developer.harness.io/harness-platform/use-harness-platform/git-experience/monitor-git-experience/overview).
recommendation: >-
  Publishing an AsyncAPI 3.0 document for the outbound notification events — even just the
  six pipeline events and their JSON payload — would close the only major contract gap in
  this platform.