Quickstart

From no account to your first completion in five minutes.

This guide walks you from “I have no AOCore account” to “I’ve made my first /v1/chat/completions call” in under five minutes. The MVP is invitation-gated, so step 1 is to obtain an invitation token — there is no open self-signup.

1. Get an invitation

AOCore MVP is invitation-gated. Ask your administrator for an invitation token.

Your administrator mints an invitation via the admin dashboard. You will receive:

  • An invitation token (an opaque string).
  • Optionally, a target email (in which case the invitation only binds to that email when you register).
  • An expiry date (typically 7 days).

If your administrator hasn’t issued you one yet, stop here and ask. There is no public sign-up endpoint, and there is no environment flag that opens one. Open self-signup is a future-objective item (it requires CAPTCHA + email verification that aren’t in the MVP scope) — for now, the only registration path is through a valid invitation token.

2. Register your developer account

Visit the developer portal in your browser (your administrator will share the URL — e.g. https://portal.core.aocyber.ai/register) and submit:

email             [email protected]
password          (12+ characters, mixed case + symbols)
invitation_token  (the token from step 1)

Equivalently, you can POST directly against the management API:

curl https://gateway.core.aocyber.ai/developer/auth/register \
  -H "Content-Type: application/json" \
  -d '{
    "email": "[email protected]",
    "password": "your-strong-password",
    "invitation_token": "your-invitation-token"
  }'

On success the response is 201 Created and you are now a developer user (user_role='developer'). Registration writes a developer_register audit row that records the consumed invitation_id for traceability. Double-redemption of the same token returns 400 with a clear error — invitations are single-use.

3. Mint your first API key

Log in (cookie-based session) and mint a key. In the portal:

  1. Click Keys in the left nav.
  2. Click + New Key.
  3. Set a key_alias — e.g. my-laptop.
  4. Choose models — the picker shows only models your developer role is allowed to grant. (Leave it empty to inherit your full developer allowlist.)
  5. Set a max_budget — start with $5.00 for testing.
  6. Click Create.

Equivalent API call (after /developer/auth/login set your session cookie):

curl https://gateway.core.aocyber.ai/developer/v1/keys \
  -H "Content-Type: application/json" \
  --cookie "aocore_dev_session=…" \
  -d '{
    "key_alias": "my-laptop",
    "models": ["gpt-4o-mini"],
    "max_budget": 5.00
  }'

The response contains the raw key under "key": "sk-…" exactly once. Copy it immediately — the portal hashes the raw value on insert and only stores the SHA256 digest. There is no “show key” recovery flow; if you lose the raw value, revoke the key and mint a new one.

4. Make your first call

Replace sk-… with the key you just minted:

curl https://gateway.core.aocyber.ai/v1/chat/completions \
  -i \
  -H "Authorization: Bearer sk-…" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [{"role": "user", "content": "Hello, AOCore!"}]
  }'

The -i flag prints the response headers, so you’ll see the six X-AOSentry-* quota headers stamped on the response — see the rate-limits guide for what each one means.

The body is the standard OpenAI chat.completion shape. Any OpenAI SDK consumes it unchanged — see examples/python-openai-sdk/chat.py for the Python equivalent.

5. See your spend

Within ~1 second of your call, the spend row is queryable. In the portal, refresh the usage page — you’ll see the spend total, the per-key breakdown, and the underlying spend_logs row.

Equivalent API call:

curl https://gateway.core.aocyber.ai/developer/v1/usage \
  --cookie "aocore_dev_session=…"

Per-key breakdown:

curl https://gateway.core.aocyber.ai/developer/v1/spend/logs?api_key_id=\
  --cookie "aocore_dev_session=…"

The freshness invariant is: by the time the /v1/* response is on the wire, the spend_logs INSERT has already committed synchronously — so the spend row is queryable by the next /developer/v1/spend/logs call without a visible delay.

Next steps