Choose the provider delivery mode from the catalog
Read the provider trigger catalog before creating a registration. Each catalog event declares one capability:
Catalog presence is not production qualification. Production provider-reaching catalog, create, inspect, reconcile, test, delete, and polling paths require the configured IntegrationRuntime and its qualified provider package. If that runtime is missing or unavailable, those paths refuse closed with typed unavailability; stored registration get and list reads remain available for diagnosis. There is no production fallback to a deterministic adapter.
Create the Automation and source binding
Create the Automation directly or apply an AutomationGraph. AWebhookSource then associates the Automation with a governed Connection and optional provider resource. It does not create a provider-side hook and does not contain a parser or relevance filter.
Either path carries an explicit environment_id. An AutomationGraph document requires environmentId, and the graph compiler forwards it into the applied Automation, so a graph and a directly created step-program Automation reach the same launch authority. The run_agent launcher projects that persisted Environment unchanged into every child Session admission. Automation readiness checks that the Environment exists, and a missing or unusable Environment fails closed before the child Session is created.
A successful graph plan or apply proves reconciliation, not that a provider event will launch the Agent. Execution qualification still needs the applicable runtime journey. Change a graph-managed Automation through its graph; patching it out of band would create competing authoring owners.
The Connection owner and ordinary governance rules remain authoritative. Credentials stay in custody and are rendered only at the qualified provider boundary. Managed provider calls bind credential resolution to the signed Connection ID, exact immutable Connection revision, and provider. A missing, stale, or mismatched binding refuses before any provider effect.
Managed registration or polling
Use catalog-derived values rather than inventing a provider event name.PROVIDER_EVENT_TYPE below must be an exact event_type returned by the catalog for the selected provider:
POST /v1/automations/{id}/provider-webhook-registrations. Its payload contains webhook_source_id, connection_id, and the catalog-derived config.
For automatic registration, Checkfu claims and creates the provider hook through the qualified runtime. Lost-response recovery adopts only an observed hook with the exact callback key and configuration fingerprint. A mismatch or unproved owner becomes degraded or indeterminate; Checkfu does not create a duplicate hook to make the UI look healthy.
For polling, the registration stores public polling configuration and an initial due state. Credentials travel through custody, not through polling_props or the registration response. The registration remains pending until the scheduler settles its first poll.
Inspect and repair provider health
ProviderWebhookRegistration owns provider-side lifecycle and health. Its statuses are:
pendingwhile initial registration or polling settlement remains incomplete;activewhen the provider lifecycle is healthy;degradedwhen an observed hook or provider test reports a recoverable mismatch;disabledafter sustained authentication failure or an equivalent bounded stop;indeterminatewhen ownership of an external effect cannot be proved;revokedordeletedafter authority is withdrawn.
- inspect is read-only and compares stored intent with the provider observation;
- reconcile repairs or adopts only when exact ownership evidence allows it;
- test asks an automatic-registration provider to send a test or schedules an immediate polling retry;
- delete removes the provider hook when applicable, fences polling, shreds the callback secret, and removes local authority.
ProviderWebhookRuntimeUnavailable; cleanup retains enough local authority to retry rather than erasing the row and orphaning an external hook.
A test or reconcile call does not bypass the Automation trigger. A provider event still enters the ordinary signed ingest path, dedupe, admission filter, and firing rules.
Manual URL and customer-hosted relay
Formanual_url, your application or integration host owns provider signature verification and provider-side URL registration. The stock @checkfu/integration-host helper verifies first, rejects verifier mutation, signs the exact original bytes for Checkfu, and delegates HTTP transport back to your host.
Relevance, dedupe, and evidence
Provider verification answers, “Did this provider send these exact bytes?” It does not answer, “Should this event launch an Agent?” The Automation’s webhook trigger owns:- dedupe through the configured JSON pointer;
- predicate filtering;
- an optional AdmissionFilter Check with an explicit fail-open or fail-closed disposition;
- prompt template rendering;
- active or paused firing state.