Flows
Policy-driven runs with evidence you can keep
Flows orchestrate what already exists in SialFlow — inspect an asset, transform an image, or move bytes on a secure-transfer path — then keep step outcomes, evidence, and lineage on the run. This is not a CDN product and not a visual builder yet.
What you get
Shipped first vertical
Inspect → image transform, and inspect → secure transfer, with publish gates that refuse secure transfer on optimized delivery.
Evidence on the run
Each step can leave allow/deny evidence and artifact lineage. That trail is separate from the outbox and from CDN cache logs.
Project isolation
Definitions and runs sit on the active project. Switch projects in the portal header; Flows never borrow another project's bytes.
Honest scope today
Templates and manual runs are in the portal. Visual builder, human review queues, and remote processors come later — we do not pretend they are live.
Differentiation
What you can run now
- Published Flow definitions with compile checks
- object.inspect with real image/object metadata
- image.transform via Studio pipelines
- transfer.secure to a project-scoped object path
- Runtime policy stubs (external processing deny)
- Deprecate and archive lifecycle
- Portal runs, evidence, and lineage detail
- OpenAPI under /v1/flows
Example
Same auth and tenancy headers as the rest of the API. Where a capability plugs into Flows today, that is called out on the product page — we do not imply every media type shares one live pipeline yet.
POST /v1/flows/{flow_id}/runs
curl -X POST "$API/v1/flows/$FLOW_ID/runs" \
-H "Authorization: Bearer $KEY" \
-H "X-SialFlow-Workspace-ID: $WORKSPACE" \
-H "X-SialFlow-Project-ID: $PROJECT" \
-H "Content-Type: application/json" \
-d '{"input":{"image_id":"img_…"},"processing_context":{"purpose_id":"manual"}}'Ship with Flows
Open the portal, follow the docs, or talk to us about rollout for your agency or commerce stack.