The FlexGalaxy.AI API¶

Every FlexGalaxy.AI capability you can call from your own code is served from one host, over HTTPS, on a versioned capability path:

https://api.flexgalaxy.ai

There is nothing else to configure. You do not address a product, a region or a service directly — you address a capability, and the edge routes it.

Capability paths¶

A path names what you are doing, not which system does it. That is deliberate: the capability path is the contract, and it keeps working when the implementation behind it changes.

Path prefix	What it covers
`/identity/v1/…`	Users, groups, policies, access keys, sign-in and token exchange
`/accounts/v1/…`	Accounts: creation, membership, lifecycle
`/organizations/v1/…`	Organizations, organizational units, and their controls
`/passport/v1/…`	Application launch and entry resolution
`/quota/v1/…`	Quota inspection and requests
`/audit/v1/…`	Audit events and export
`/developer/v1/…`	Developer-programme registration and application credentials
`/service-catalog/v1/…`	The catalogue of callable services and their capabilities

Anything outside these prefixes is not part of the public contract. If your integration seems to need something you cannot find above, request a partner API rather than calling a path you discovered — undocumented routes are not covered by any compatibility promise and are expected to change without notice.

API reference¶

The full, versioned reference lives at docs.flexgalaxy.ai/api/, with one section per product:

DotID — identity, accounts, organizations, quota, audit, app launch
TrustMint — devices, models, certificates, telemetry, twins, pipelines, OTA
Bazaar — marketplace publishing, entitlements, catalog, commerce, signing

Each reference is generated from the specification the product actually ships and is then reconciled against the routes the edge actually serves, so a path you can read there is a path you can call. Nothing on that surface is hand-written.

https://api.flexgalaxy.ai/ in a browser redirects to that reference.

Authenticating¶

Two credential types reach the API, and which one you use depends on who is acting.

A service you own — AK/SK request signing. Issue an access key, then sign each request. This is the right choice for backend integrations, scheduled jobs and anything running without a person present.

curl -sS https://api.flexgalaxy.ai/identity/v1/users \
  -H "Authorization: FGAI-HMAC-SHA256 Credential=$FGAI_ACCESS_KEY_ID/…" \
  -H "X-Fgai-Date: $(date -u +%Y%m%dT%H%M%SZ)"

A signed-in person — a bearer token. Your application completes an OIDC login and forwards the resulting access token:

curl -sS https://api.flexgalaxy.ai/accounts/v1/accounts \
  -H "Authorization: Bearer $ACCESS_TOKEN"

The fgai command-line tool handles both for you; see the CLI guide if you would rather not sign requests by hand.

Note

Do not call identity-provider administration APIs directly, even if you can reach them. Account and user administration is exposed through /identity/v1/… and /accounts/v1/…, which apply the authorization model your account is governed by. A direct call bypasses it, and the boundary is enforced, not merely documented.

Errors¶

Errors are JSON and carry a stable code you can branch on. Read the code, not the human-readable message, which is free to change.

Status	Meaning	What to do
`400`	The request was malformed	Fix the request; retrying will not help
`401`	Missing, expired or invalid credentials	Refresh the token or re-sign the request
`403`	Authenticated, but not permitted	You need a policy grant, not a retry
`404`	No such resource, or not visible to you	Check the identifier and the account you are acting in
`409`	Conflicts with the current state	Re-read the resource and retry the change
`429`	Rate limited	Back off; see below
`5xx`	The platform failed	Retry with exponential backoff and jitter

Rate limits¶

Requests are rate limited per credential. A limited response is 429 and carries Retry-After in seconds — honour it rather than retrying immediately, because a tight retry loop is counted too. Back off exponentially with jitter for 429 and 5xx; do not retry 4xx responses other than 429.

Versioning¶

The v1 in a capability path is the compatibility promise. Within v1 we add fields and add endpoints; we do not remove or repurpose either. Treat unknown response fields as forgivable and ignore them — that is how additive change stays non-breaking for you.