> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akua.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Order drafts
> The state machine a customer moves through from opening an offer to a live installation
An order draft is the working record of one customer's journey from opening an [Offer](/marketplace/offers) to starting a running [installation](/installs). It is created the moment a customer opens an offer link, and it carries every choice they make along the way: who they are, which workspace receives the install, the inputs they configure, and whether payment is required. The draft advances through a fixed sequence of states, and it is the main thing both the customer's install wizard and your seller dashboard read to know where the customer is right now.
Most customers never see the term "order draft"; they just walk through the guided wizard. As a seller, the draft is how you watch that walk: a draft sitting in `configure` for a long time is a customer stuck on a form, and a draft in `payment` is one who reached checkout but has not paid yet.
## The customer flow
```mermaid theme={null}
%%{init: {'flowchart': {'nodeSpacing': 55, 'rankSpacing': 60, 'curve': 'basis'}}}%%
flowchart TB
OFFER["Customer opens an Offer"]
CLAIM["Claim — sign in and bind the draft"]
WS["Select or create a workspace"]
COMPUTE["Allocate compute"]
BOOT{"New cluster needs
a worker?"}
JOIN["Join a worker node"]
CONFIG["Configure the install"]
PAY{"Payment
required?"}
CHECKOUT["Complete checkout"]
INSTALL["Create the installation"]
LIVE["Installation live"]
ENDED["Cancelled or ended"]
OFFER --> CLAIM --> WS --> COMPUTE --> BOOT
BOOT -->|yes| JOIN --> CONFIG
BOOT -->|no| CONFIG
CONFIG --> PAY
PAY -->|yes| CHECKOUT --> INSTALL
PAY -->|no| INSTALL
INSTALL --> LIVE
CLAIM -.-> ENDED
WS -.-> ENDED
CONFIG -.-> ENDED
```
The branches matter: the worker-join step only appears when the chosen destination is a brand-new managed cluster with no worker yet, and the checkout step only appears when the offer's commercial terms require payment. A free or private offer on an existing cluster runs the short path straight from configure to install.
## The states
Each order draft reports a `status` that names its current state. The states run in order, and `done` and the cancelled state are terminal.
| State | What is happening |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Resolve the offer** | The customer opens `akua.dev/i/`. Akua resolves the offer and creates an order draft against it, still anonymous. |
| **Claim** | The customer signs in (or signs up with email verification) and claims the draft with a one-time token, binding it to their account. |
| **Workspace** | The customer picks an existing [workspace](/workspaces) or creates a new one as the install destination. |
| **Compute** | Akua allocates the cluster the installation will run on. |
| **Worker bootstrap** | Only when the destination is a new managed cluster with no worker: the customer adds a [worker node](/clusters/add-workers) using a short-lived join command, and the draft waits until the node is ready. |
| **Configure** | The customer fills the generated install form. Fields come from the Package version's input schema, with any offer pre-fills and locked fields already applied. |
| **Payment** | Only when the offer requires payment: the customer completes a hosted checkout. |
| **Install** | Akua creates the installation, provisions the customer's [private repository](/installs/repositories), and deploys the selected Package version. |
| **Live** | The installation is running and the order is delivered. |
A draft can also be **cancelled** by the customer, or end on its own when the offer expires, a checkout is abandoned past its window, or an install cannot complete. An ended draft is terminal; the customer starts over with a fresh offer redemption.
## Where payment fits
The payment state is a branch, not a fixed step. When an offer carries paid commercial terms, the draft cannot reach the install state until a checkout session is completed and confirmed. Akua opens a Stripe-hosted checkout, and the customer returns to the wizard once payment succeeds. If a checkout fails or is abandoned, the draft stays in the payment state and the customer can start a new checkout session.
When an offer is free or settles outside checkout (a private sale, or a non-billable test offer from an [offer channel](/marketplace/offer-channels)), the draft skips payment entirely and moves straight to install. Paid checkout is enabled for workspaces as the commerce path rolls out.
## Adding a worker when needed
If the customer routes the install to a freshly created managed cluster that has no compute yet, the draft pauses so they can attach one. Akua issues a short-lived bootstrap command and cloud-init that join a [worker node](/clusters/add-workers) to that cluster. Once the node is ready, the draft continues to the configure state. Installs that target an existing cluster with available capacity never see this step.
## What happens after the draft
The order draft is not the whole lifecycle. It owns the purchase and configure flow up to the point where the install can begin. Once payment is complete, or once a no-charge offer skips payment, Akua records the order, starts delivery, and links the draft to the installation it creates.
From that point, the installation becomes the long-lived resource. Use the draft to understand where a buyer is in the purchase flow. Use the [installation lifecycle](/installs/lifecycle) to monitor the running software: render history, health, pods, logs, and deletion.
## Seller visibility
The order draft is the same record behind the offer's support-visibility view. Watching a customer's drafts tells you where each buyer is in the flow and where they drop off, without exposing their secret configuration values. Sensitive inputs are write-only and are never returned to anyone but the customer who entered them. This is how you support a customer mid-purchase: confirm they reached checkout, see that delivery has started, or spot a draft that ended early.
## API
Track and manage customer order drafts and their checkout sessions programmatically.
Inspect, claim, configure, and cancel order drafts through the flow.
Create and read the checkout sessions attached to a paid order draft.
Create and resolve the offers that start an order draft.
Mint API tokens for seller-side automation.
## Related topics
The shareable links that start every order draft.
Configure the sellable product behind an order draft.
Attach a worker node when an install needs new compute.
What the order draft produces once it goes live.