Skip to main content
A provider event crosses several authorities before an Agent runs:
The provider lifecycle does not own the Automation, and the Automation does not own the provider credential.
The Checkfu CLI and TypeScript SDK are private-alpha artifacts with no self-service public installation channel. Part of this flow is behind a rollout fence; a deployment that has not enabled it refuses the request rather than running it. Confirm capability status before making availability part of your application’s contract.

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.
The fake provider and fake GitHub adapter are test and scenario infrastructure only. They are exposed by the explicit fake runtime used in tests, never by production composition. A passing fake journey is not provider support evidence.

Create the Automation and source binding

Create the Automation directly or apply an AutomationGraph. A WebhookSource 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:
The REST resource is 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:
  • pending while initial registration or polling settlement remains incomplete;
  • active when the provider lifecycle is healthy;
  • degraded when an observed hook or provider test reports a recoverable mismatch;
  • disabled after sustained authentication failure or an equivalent bounded stop;
  • indeterminate when ownership of an external effect cannot be proved;
  • revoked or deleted after authority is withdrawn.
Use the lifecycle operations deliberately:
  • 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.
A runtime outage is not evidence that a provider hook is absent. Production returns 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

For manual_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.
The helper is not a universal provider verifier. Your verifier must implement the selected provider’s exact signature protocol, and your server must capture raw bytes before parsing.

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.
A deliberately filtered event is recorded as a filtered delivery. A deduplicated replay settles against the original firing. An accepted event creates an AutomationRun. If the target is an Agent and admission succeeds, the AutomationRun links to the new Session and initial Run, while the Session log records the Agent execution.

Revocation boundaries

Revoking the Connection prevents future provider access without deleting the Automation. Deleting a WebhookSource removes that inbound binding. Deleting a ProviderWebhookRegistration withdraws provider-side or polling authority. Pausing the Automation stops new work while preserving all of those resources for inspection. Deleting the Automation removes its own trigger authority and follows its documented child cleanup rules. These operations are separate because they answer different trust questions. Do not substitute one for another in an incident response runbook.