CLI reference

The fgai command-line interface is a thin, uniform front end over the same public Bazaar API you can call directly over HTTPS. Every command maps one-to-one to a /<capability>/v1/... endpoint on api.flexgalaxy.ai — the CLI adds nothing the API does not expose, and exposes nothing the API does not.

The Bazaar commands ship inside the single fgai binary alongside the other FlexGalaxy.AI tiers.

Command shape

fgai <group> <verb> [--<id> <value> ] [--body <json> | --body-file <path>] [--idempotency-key <key>]
  • <group> is a capability group (below). Most groups have short aliases (e.g. dev2mpublisher, otarollouts).

  • <verb> is the operation (fgai <group> --help lists them).

  • Path identifiers are passed as flags (--request, --grant, --rollout, …).

  • Writes take a JSON body via --body or --body-file (- reads stdin). A random Idempotency-Key is generated per write unless you pass one — supply a stable --idempotency-key to make retries idempotent.

  • Responses print as pretty JSON; a successful empty response prints ok.

Authentication

The CLI resolves credentials from your active fgai profile (fgai configure):

Credential

Header

Groups

Interactive user

Authorization: Bearer <token>

tenant / publisher groups

Access key / secret key

Authorization: FGAI-HMAC-SHA256

external-licensing (external integrator API)

none

marketplace, signing-keys (public discovery)

Capability groups

Group (aliases)

What it drives

licensing (licenses)

EntitleKit — license request lifecycle, grants & assignments, revoke / renew

commerce (billing)

EntitleKit — account billing profile & commercial change preview / confirm

external-licensing

External integrator licensing API (AK/SK) — poll requests, post decisions & compensations, delegate an offer’s approval, change feed, licensed-subject roster, webhooks, sandbox

rollouts (ota)

OTAForge — OTA rollout preview / create / drive / reconcile

publisher (dev2m)

Dev2M — publisher profiles, products, releases, reviews, offers, channels, rollout requests, lifecycle

marketplace (listings)

Marketplace — public marketplace listing browse

inventory

EntitleKit — your acquired applications + terminal assignments

app-provisioning (acquire)

EntitleKit — acquire / assign application provisioning + request voting

signing-keys (keys)

Public artifact-signing key discovery

Run fgai <group> --help for the full verb list of any group.

Examples

# Publish flow (Dev2M): create a product, then a release
fgai publisher product-create --body '{"slug":"clean-suite","kind":"APPLET","title":"Clean Suite","summary":"Floor cleaning applet"}'
fgai publisher release-create --product <product-id> --body-file release.json
fgai publisher release-submit --release <release-id>

# Declare (or re-declare) which device models the product runs on. This is what the
# SkillStore `--model` filter matches, and it can be changed after the product exists.
fgai publisher product-compatibility --product <product-id> \
  --body '{"compatibility":[{"platform":"device","vid":"broit","model":"broit-cleaner-x1"}]}'

# Browse the public marketplace — no credential required
fgai marketplace list
# --listing takes the numeric listing id from `marketplace list`, not a slug
fgai marketplace get --listing 12

# Fetch the public artifact-signing key
fgai signing-keys platform

Listing licence requests across an organization

A licence request is held by the account that owns its subject — for a robot, the account that owns the robot, which is often a member account rather than the one that filed the request. licensing requests-list therefore takes an organization scope:

# Your own account's requests (default)
fgai licensing requests-list

# Every request held by your organization's member accounts
fgai licensing requests-list \
  --scope-type ORG --target-frn "frn::bazaar:org/<organization-id>"

Over HTTPS the same read is GET /software-licensing/v1/requests?scope_type=ORG&target_frn=frn::bazaar:org/<organization-id>.

Each row carries the accountId that holds it, so you can answer “which of my sites hold a licence for this” and spot two requests for the same subjectFrn — retract the surplus one with licensing requests-withdraw --request <id>.

The organization scope is authorized on the organization, not on the individual accounts: your organization’s management account sees all of them, and a partner you have delegated to sees exactly the accounts its delegation covers. A caller with neither is refused rather than shown an empty list.

Acting on a request by id

Listing across an organization and operating on a request are authorized differently. Every per-id operation — requests-get, requests-submit, requests-withdraw, requests-decide, requests-issue, and the grant verbs — is authorized against the account that holds the request. You can act on it if that account is your own, or if you hold a delegation covering it; otherwise the call is 403 forbidden. Seeing a row in the organization-scoped list does not by itself grant you authority over it.

An offer declares its commercial terms and where the resulting license is held — see Offers. A release body may declare a publish-time application config-schema — see Application config-schema.

Note

Marketplace moderation (review decisions, delisting, feature flags) is a console-only platform surface and is deliberately absent from the CLI.