Provider Triggers

Many catalog providers describe trigger definitions alongside their actions — metadata about the external events that provider can emit (e.g. issues.opened on GitHub). Datafuse currently exposes this metadata for discovery and forwards organization audit events to a configured webhook. It does not yet run an active, per-connection webhook ingress or an SDK-level subscribe() callback API — treat any such example as a roadmap illustration, not a working feature.

1. Discovering a Provider's Trigger Definitions

Each catalog provider that declares triggers exposes them read-only via the provider detail route:

curl -sS "$DATAFUSE_API_URL/api/v1/providers/github/triggers"

This returns the raw triggers array from that provider's manifest — slug, name, description, event_type, and a payload_schema describing the shape of the event if the provider ever delivers it. It is catalog metadata for planning your integration; it does not register a live subscription.

import requests

triggers = requests.get(
    f"{base_url}/api/v1/providers/github/triggers"
).json()

for trigger in triggers:
    print(trigger["slug"], trigger["event_type"])

2. What Is Implemented Today: Organization Audit Webhooks

The one webhook delivery mechanism that is live in the platform forwards organization audit log events (not provider triggers) to a URL you configure on your organization:

curl -sS -X PUT "$DATAFUSE_API_URL/api/v1/organizations/me" \
  -H "Authorization: Bearer $DF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"webhook_url": "https://example.com/datafuse/audit-events"}'

Once set, audit log entries created for your organization (see POST /api/v1/audit/logs) are POSTed to webhook_url on a best-effort basis via httpx only when the organization has Zero-Retention Mode enabled (zero_retention: true on the organization). In that mode the event is forwarded to your SIEM/webhook and is not persisted in the Datafuse DB; with Zero-Retention off, audit events are persisted normally and no webhook delivery occurs. This is the "zero-retention forwarding" path described in Observability and Auditing — it carries audit events, not raw third-party provider payloads.

Roadmap

Per-connection provider event ingestion (e.g. a live GitHub webhook that fires your agent loop automatically) is on the roadmap but not shipped. If you need that behavior today, poll the relevant provider's API directly, or register your own webhook receiver with the third-party provider and call the Datafuse invoke route from your handler.

Next Steps

• Review the client overview for the routes that are live today.
• See Observability and Auditing for how audit-event forwarding works.