Skip to main content

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.

A conveyor of order states runs left to right — offer, claim, workspace, configure — then forks at a payment decision into a checkout path and a no-charge path that converge on a live installation
An order draft is the working record of one customer’s journey from opening an Offer to starting a running installation. 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

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.
StateWhat is happening
Resolve the offerThe customer opens akua.dev/i/<hash>. Akua resolves the offer and creates an order draft against it, still anonymous.
ClaimThe customer signs in (or signs up with email verification) and claims the draft with a one-time token, binding it to their account.
WorkspaceThe customer picks an existing workspace or creates a new one as the install destination.
ComputeAkua allocates the cluster the installation will run on.
Worker bootstrapOnly when the destination is a new managed cluster with no worker: the customer adds a worker node using a short-lived join command, and the draft waits until the node is ready.
ConfigureThe 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.
PaymentOnly when the offer requires payment: the customer completes a hosted checkout. See payments.
InstallAkua creates the installation, provisions the customer’s private repository, and deploys the selected Package version.
LiveThe 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), the draft skips payment entirely and moves straight to install. The full payment lifecycle, platform fees, and Stripe Connect setup live in Marketplace payments.

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 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 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.

Order Drafts API

Inspect, claim, configure, and cancel order drafts through the flow.

Checkout sessions API

Create and read the checkout sessions attached to a paid order draft.

Offers API

Create and resolve the offers that start an order draft.

Authentication

Mint API tokens for seller-side automation.

Offers

The shareable links that start every order draft.

Payments

The checkout and billing flow behind the payment state.

Add workers

Attach a worker node when an install needs new compute.

Installations

What the order draft produces once it goes live.