Provisioning keys for your users

If you're building a product on top of FluidGhost — where your users each need their own access and you drive the settings from your own panel — you don't hand everyone your account key. Instead you get one management key and use it to mint a sub-key per user, programmatically.

This is the B2B path. (If you just want to call FluidGhost from your own backend, a plain secret key is all you need.)

The model

Your account
├── Management key (fg_mgmt_live_…)   ← you, in the dashboard
│      │  provisions ↓ (POST /api/v1/keys)
│      ├── Sub-key → your user A   (identity: "user-a")
│      ├── Sub-key → your user B   (identity: "user-b")
│      └── …

• The management key can only mint/rotate/revoke sub-keys. It can't submit jobs or spend — so it's safe on your provisioning server.
• Each sub-key is an ordinary secret key that can run jobs. It belongs to your account (jobs bill your balance) and carries the identity you set, so you can attribute usage per user.
• Your users' panels send settings per call (or you bind a default preset per sub-key). See Configuring your own settings.

1. Get a management key

In the dashboard → API keys, choose the Management type and create it. Store it as a secret on your backend. It looks like fg_mgmt_live_….

2. Mint a sub-key when a user signs up

curl -X POST https://api-ghost.fluidvip.com/api/v1/keys \
  -H "Authorization: Bearer $FLUIDGHOST_MGMT_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "identity": "user-a", "label": "user A" }'

{ "id": "key_…", "key": "fg_sk_live_…", "identity": "user-a", "selfServe": true }

Store the key for that user (it's shown once), or hand it to their client to use directly.

3. Your user runs jobs with their sub-key

Exactly like any secret key — your panel sends the settings:

curl -X POST https://api-ghost.fluidvip.com/api/jobs \
  -H "Authorization: Bearer fg_sk_live_…" \
  -F image=@photo.jpg \
  -F 'options={"noise":35}' -F copies=3

API-key jobs are one-time (ephemeral) by default — results delete on download.

4. Manage the fleet

• List what you provisioned: GET /api/v1/keys (returns only your sub-keys).
• Rotate a user's key: POST /api/v1/keys/{id}/rotate — the old secret works for 24h so they can swap without downtime.
• Revoke a user (e.g. they cancel): DELETE /api/v1/keys/{id} — immediate.

Full endpoint details: Provisioning reference.

Notes

• No privilege escalation. A sub-key is always a plain secret key — it can never mint other keys, and a management key can't mint another management key.
• Isolation. You only ever see or manage the keys you provisioned; sub-keys can't see each other or your account.
• Billing currently hits your one shared balance for all sub-keys. Per-user spend caps are on the roadmap — for now, rotate/revoke are your controls.