Checking status¶
Four different things can be “in progress” at once — an acquisition, a license, a rollout, and a payment — and each has its own place to look. Reading the right one saves a support call.
What my account has¶
Marketplace → My apps lists everything the selected account has acquired: the product, the offer you took it on, the current state, and when it was acquired. Open a row to go back to the listing, where the button reflects the same state.
While an acquisition is running, the state moves through Requested and settles on Configure or, if something went wrong, Retry. It refreshes on its own; you do not need to reload the page.
Licenses and requests¶
EntitleKit holds the license side: requests waiting on a decision, issued licenses with their validity windows, the seats assigned against them, and the history of every change.
Read the state name literally — the lifecycle deliberately keeps apart things that are easy to confuse:
Approved is not Issued. Approval is a decision; issuance is the minting of the license. A request can sit between the two.
Failed is not Refused. Failed is technical and retryable; refused is a verdict with a reason.
Withdrawn is not Refused. Withdrawn is the requester taking it back before anyone decided.
The full list is in When a license needs an approval.
Every request carries a ledger: each state change with who caused it, when, and why. It is append-only — a correction is a new entry, never an edit — so it is a usable answer to “what actually happened to this request”.
Rollouts¶
OTAForge shows rollouts and the robots in them. Two numbers on a rollout look similar and are not:
Requested state — what you asked for (start, pause, resume, cancel, retry).
Confirmed state — what the fleet-management system has actually done.
They differ for as long as an operation is in flight. Never read a requested state as proof that the fleet has changed.
Per-robot outcomes are kept separate rather than collapsed into one percentage, because the remedies differ: downloading and installing are progress, offline is a robot that has not reported yet, incompatible is a robot the version does not fit, and rejected and failed are refusals to act on. Filter by outcome and treat each group differently.
A rollout that starts failing pauses itself. Each rollout carries a failure threshold; once the share of failed or rejected robots reaches it, the platform pauses the rollout and records why. Nothing resumes automatically — you look, fix, and resume deliberately.
Billing¶
EntitleKit → Billing carries the account’s billing profile, plan, invoices and
payments (the console app is where invoices and payment history are read; the fgai
CLI’s commerce commands cover the profile and commercial changes). A commercial change
is always two steps: preview it and read exactly what it will cost and alter, then
confirm. A preview changes nothing, so it is safe to run one just to see the number.
What Bazaar does — and does not — record¶
Bazaar records what is licensed: the entitlements, their subjects, and their terms. It does not record what a robot does with the software. Usage capture (telemetry, counters, metering) is not a Bazaar surface — it is granted per scope by the device owner to a metering integrator; Bazaar holds the license, the device plane holds the telemetry.
When something is refused¶
A refusal is an answer, not a fault. It usually means one of three things:
You lack the permission. Acquiring, assigning, approving, deploying and billing are separate grants. Ask your administrator for the one the action names.
The account is not the right one. Everything is scoped to the account selected in the top bar. A license held by a sister site is not visible from yours.
A precondition is not met — no seats free, the product not held by the owning account, or a version that does not fit the target robot.
Error messages deliberately do not reveal whether a resource exists in an account you cannot see. A “not found” on something you believe exists usually means the selected account is wrong.