Integrate with Alfred's durable workflow API and operate the service safely.
Alfred exposes infrastructure operations as authenticated, asynchronous workflows. An accepted request creates a durable execution that can be queried, streamed, retried when eligible, or compensated when the workflow supports it.
Executions are the public authority
A workflow response acknowledges durable work; it is not the provider result. Read the execution and its events until Alfred reports a terminal status.
See the five supported workflows and their configuration gates.
Authenticate, submit a safe dry run, and inspect its execution.
Poll executions, stream progress, and apply supported controls.
Choose durable readback, SSE, or signed webhook delivery.
Learn the process, persistence, delivery, and provider boundaries.
Separate liveness, dependency readiness, and provider validation.
Retry, resume finalization, or compensate eligible executions.
Launch, track, approve, and recover guided workflows.
| Surface | Purpose |
|---|---|
/openapi.json | Client OpenAPI 3.1 contract for workflows, executions, events, streams, and subscriptions. |
/openapi.operator.json | Operator OpenAPI 3.1 contract for health, observability, audit, administration, and API keys. |
/docs/reference/api | Rendered endpoint and schema reference generated from the client contract only. |
/v1/events/catalog | Versioned event catalog with JSON Schemas. |
/llms.txt | Compact machine-readable documentation index. |
/llms-full.txt | Flattened authored documentation corpus. |
Current TypeScript and Zod schemas define behavior. The generated OpenAPI documents define the client and operator HTTP contracts. Adapter ingress such as Slack, GitHub, and Zendesk hooks is intentionally excluded from both generated contracts. Authored pages explain how to use the contracts without duplicating every operation schema.