Approval workflows
Status: detailed reference content coming soon. The summary below
describes the model; specific event names and state-machine
diagrams will land in the next iteration alongside protocol detail.
The model
An approval workflow is a sequence of stages, each with three possible outcomes:- Approved — move to the next stage (or, if final stage, to delivery).
- Rejected with feedback — return to a previous stage with the reviewer’s notes.
- Escalated — pause for a defined party (you, the buyer, the platform) to make a call.
When approval workflows are right
- Your service has an existing human review process you want to preserve.
- The output is sensitive enough that the buyer would expect human oversight (legal documents, brand-critical creative, regulated industries).
- You can return status updates at meaningful checkpoints, not just on the final completion.
When they’re overkill
- Your work is fully automated and completes inside the standard bidding window. Use the synchronous path — adding approval stages for the sake of it adds latency without value.
- The “approval” is just internal quality assurance with no decision to make. Same answer — use the sync path.
What this page will cover
- Stage definition: how to declare your workflow’s stages at registration
- Status update events: when to fire them, what payload to include
- Approval, rejection, and escalation events
- How buyers see workflow status in their task view
- Cancellation in the middle of a workflow: what to do with in-flight human review
- Audit trail: what’s logged and visible to which party