Resource lifecycle
Overview
Every marketplace order moves through a fixed state machine; once an order succeeds, the resource it creates has its own state machine. Operators and integrators rely on these two state machines to interpret webhook events, debug stuck provisioning, and write policies.
Order states
| State | Code | Meaning |
|---|---|---|
| pending-consumer | 1 | Awaiting approval from the consumer organization. |
| executing | 2 | Backend provisioning in progress. |
| done | 3 | Resource provisioned successfully. |
| erred | 4 | Provisioning failed; admin or retry needed. |
| canceled | 5 | User canceled before processing. |
| rejected | 6 | Approval denied. |
| pending-provider | 7 | Awaiting approval from the service provider. |
| pending-project | 8 | Awaiting in-project approval (when configured). |
| pending-start-date | 9 | Approved but waiting for the configured start date. |
Resource states
| State | Code | Meaning |
|---|---|---|
| Creating | 1 | Initial provisioning underway. |
| OK | 2 | Steady state; usage being reported. |
| Erred | 3 | Last operation failed; resource is in an inconsistent state. |
| Updating | 4 | A modify order is being applied. |
| Terminating | 5 | Cleanup in progress. |
| Terminated | 6 | Resource removed from the backend; record retained for billing. |
Recovering an erred order
A staff user can retry an erred order from the UI or via the API. Retry locks the row, re-checks the state inside a transaction, and re-enqueues the backend operation — see the backend concurrency guidance for the implementation detail.
Related concepts
- Marketplace — where orders originate.
- Policies — automated reactions to state changes (e.g. terminate on overspend).
- Call management — proposals that produce orders on approval.