API · Tooling
Composite workflows
One-shot endpoints that wrap multi-resource lifecycle operations
Last updated
TL;DR
When a workflow crosses multiple resources — charter amendment + share class
- ledger entries + grants + filing — Matter ships it as one
POST /workflows/<verb>endpoint instead of asking the caller to orchestrate. Every workflow is idempotent (Idempotency-Keyrequired), reports per-step status, and never half-applies. Long-running ones return202 Acceptedand emitworkflow.completedon the bus.
Some operations are too sequential to leave to client orchestration. Composite workflows are first-class endpoints under /workflows/* that wrap a multi-step operation into a single transactional call:
| Endpoint | What it does |
|---|---|
POST /workflows/file_all_due | Sweeps every entity in scope, queues every overdue or due-this-period filing, returns a digest. |
POST /workflows/issue_priced_round | Charter amendment + share-class creation + ledger entries + grants + filing — atomic. |
POST /workflows/dissolve_company | Drives the dissolution cascade end-to-end (see Dissolution). |
POST /workflows/acquire_company | M&A close — buy-side counterpart to a corporate_transaction reaching closing. |
Why these are platform-tier
Composite workflows aren't lifecycle-phase-specific — they cross Create, Manage, and Exit. They live under Platform because they're an orchestration primitive, used by the lifecycle phases rather than belonging to one.
Idempotency
Every composite workflow requires Idempotency-Key. The token-scoped 24h retention means a retried call returns the original result. Partial failures inside the workflow are reported per-step in the response — no step half-applies.
Related
- Cookbook — end-to-end recipes that compose these primitives.
POST /workflows/file_all_duePOST /workflows/issue_priced_round
Long-running workflows return 202 Accepted and deliver completion via webhook (workflow.completed). Short ones (e.g., file_all_due for a single entity) return synchronously.