Tasmanian Cloud documentation
Events and webhooks
Connect resource state to the systems around your infrastructure
Resource state is useful outside the portal. Tasmanian Cloud emits events for the changes that matter to an operating system: requests, plans, runs, failures, verified outputs, patch findings, and resource changes.
Webhook flow
sequenceDiagram
participant R as Resource runtime
participant W as Webhook receiver
participant S as Your system
R->>W: Signed event
W->>W: Verify and record
W->>S: Trigger action
S->>R: Read detail or reconcileUse webhooks for deployment pipelines, audit records, ticket systems, internal dashboards, and machine-to-machine workflows. The receiver should verify the message, record the event, and decide whether it needs to read more detail from the API.
Do not confuse signals with state
A webhook says that something changed. The API remains the source for the full resource state and reconciliation. A missed event must be recoverable by reading current state. A duplicate event must be safe to record or process again.
Secret handling
Webhook signing keys and credentials can be held as Kleis references. The event receiver gets the verification or delivery capability without placing the raw secret in a template or AI context window.
Patch findings
Host and image package findings belong in the same operating workflow as deployment state. A finding can carry the asset, package state, severity, scan time, first-seen time, and remediation state. A customer can read it through the API and choose whether to request a reconfigure, acknowledge it, or continue monitoring.
Patch findings can also emit delivery events. Use a webhook for a remediation system, an email report for a scheduled review, or an ntfy-compatible provider for an urgent operational signal. Delivery does not change the health state of the workload.