iblai-api-login

iblai-api-login

Connect an organization so the other iblai-* skills can call the ibl.ai platform. Every API call needs three things — your org key, your username, and a Platform API Token — and this skill collects all three and writes them to .env. Run it once per organization.

What you are collecting

Value	Goes in `.env` as	Where it comes from
Org key	`IBLAI_ORG`	`login.iblai.app/me` → the key of the chosen org
Username	`IBLAI_USERNAME`	`login.iblai.app/me` → account / profile
Platform API Token	`IBLAI_API_KEY`	An Api-Token minted from the session — see step 2

The base URL is fixed: https://api.iblai.app. Auth header on every request is Authorization: Api-Token <IBLAI_API_KEY>.

Fastest path — org credentials (key + secret)

If you already hold organization credentials — an org key and an org secret (issued for the org for automation/CI; the same pair the ibl.ai quickstarts use) — you can skip the browser entirely. The org secret works directly as the Platform API Token; there is nothing to mint:

IBLAI_ORG=<org key>          # e.g. acme
IBLAI_API_KEY=<org secret>   # used verbatim as: Authorization: Api-Token <secret>

The only value left is IBLAI_USERNAME. Read an admin username straight from the API with the two values above — no /me page needed:

set -a; . ./.env; set +a
curl -s "https://api.iblai.app/dm/api/core/platform/users/?platform_key=$IBLAI_ORG&platform_org=$IBLAI_ORG&page=1&page_size=5" \
  -H "Authorization: Api-Token $IBLAI_API_KEY" \
  | python3 -c "import sys,json;[print(u['username'], u.get('is_admin')) for u in json.load(sys.stdin)['results']]"
# pick an is_admin=True username → IBLAI_USERNAME

Then skip to step 3 (save to .env) and step 4 (verify). The browser-session flow below is only for when you don't have org credentials and must mint a token from a signed-in session.

Get the user signed in

This skill needs a signed-in login.iblai.app/me session. Two paths:

No account, or no org of their own? Send them to https://ibl.ai/join. Signing up creates their account and their organization and leaves them logged in — that's everything this skill needs. (This also covers the user who only sees the shared main org: main is the default everyone lands in, not their own workspace, so they still need to join/create one.)
Already have an account? Have them sign in at https://login.iblai.app/me.

Never enter the user's credentials for them — let them complete the login, then read the values off the page.

Tip — use browser automation. This skill is smoothest when the agent can drive a browser (e.g. the user launches claude --chrome): it can read the signed-in session and mint the API token automatically (step 2). Without a browser, the user pastes a token instead — recommend they relaunch with claude --chrome for the automated path.

Steps

Read the org key and username off /me.

Navigate to https://login.iblai.app/me. If it redirects to a sign-in screen, the user isn't logged in — point them at the paths above and wait for them to confirm. After login the platform redirects elsewhere (the destination varies), not back to /me — so always re-navigate explicitly to https://login.iblai.app/me before reading.

/me is server-rendered (no JSON API), so read the values off the rendered page content. It shows the account (username/email) and the list of organizations the user belongs to; each org block is the display name followed by its key — e.g. enterprise, a company slug, or a UUID like 3b42a400a2fc4ec9…. Accounts can belong to many orgs (40+ is normal), so always ask the user which org to target → IBLAI_ORG, and capture the account username → IBLAI_USERNAME.
Mint a Platform API Token from the session.

API calls authenticate with an Api-Token, not the browser login.
- With browser automation (recommended): the signed-in login.iblai.app session carries a short-lived auth token in localStorage as dm_token. Use it with the Token scheme (not Bearer — Bearer returns 401) to create a Platform API Token (the same POST …/platform/api-tokens/ call documented in /iblai-api-token):
```
POST https://api.iblai.app/dm/api/core/platform/api-tokens/
Authorization: Token <dm_token from login.iblai.app localStorage>
Content-Type: application/json

{ "username": "<username>", "name": "iblai-cli", "key": "",
  "platform_key": "<org>", "created": "<ISO-now>", "expires": "" }
```
  Capture the returned secret (shown once) → IBLAI_API_KEY.
  
  Token uniqueness: (platform_key, name) must be unique. Re-running with the same name for an org returns 400 … must make a unique set — use a fresh name (e.g. iblai-cli-<org>) or reuse the existing token.
  
  Which org the token targets. The platform_key in the request body scopes the resulting token — an admin's dm_token can mint a token for any org they administer. The dm_token itself is tenant-scoped, though, so if minting fails with 401/403, switch the active tenant and re-read it: open os.ibl.ai, use the org dropdown (top-right), select the target org (URL becomes os.ibl.ai/platform/<org>/…), then read the refreshed dm_token from that page's localStorage.
- Without a browser: if you have org credentials (key + secret), skip this step entirely — the org secret is the IBLAI_API_KEY (see Fastest path — org credentials above). Otherwise, have the user create a token in the platform admin (or at login.iblai.app) and paste the secret; recommend claude --chrome to automate it.
Save to .env (and make sure it's gitignored).
```
IBLAI_ORG=<org key>
IBLAI_USERNAME=<username>
IBLAI_API_KEY=<token>
```
Before writing it, guarantee .env is ignored by git — check .gitignore and add a .env line if missing (create .gitignore if the project has none), so the token can never be committed.

Every other iblai-* skill reads these values. To make them live in shell commands, source .env (set -a; . ./.env; set +a) before API calls — or, in Claude Code, mirror them into .claude/settings.local.json env (also gitignored) for automatic injection.
Verify the connection.

Confirm the token authenticates against a real data endpoint. Do not use the …/platform/api-tokens/ management endpoint — it only accepts the session Token <dm_token> scheme and returns 401 for any Api-Token, valid or not, so it cannot confirm a minted token works:
```
curl -s -o /dev/null -w '%{http_code}\n' \
  "https://api.iblai.app/dm/api/core/platform/users/?platform_key=$IBLAI_ORG&platform_org=$IBLAI_ORG&page=1&page_size=1" \
  -H "Authorization: Api-Token $IBLAI_API_KEY"
```
A 200 means you are connected. Report the active org and username back to the user.

Notes

{org} (a.k.a. platform_key), {username}, and {mentor} (agent unique id, e.g. d17dc729-60fd-4363-81a0-f67d9318b03e) are the path variables every other skill substitutes.
One organization = one org key + one Api-Token. To switch organizations, re-run this skill and pick a different org on /me.