Developers

Authentication

Every request to /api/v1 is authenticated with a bearer key. Keys are full-scope by default so an agent can operate index365 out of the box, organization-scoped, and revocable instantly.

Sign in from the CLI (recommended)

The fastest way to get a key onto a machine is index365 login. In a terminal it asks how you want to sign in:

index365 login   # asks how you want to sign in, then saves a key (0600)
index365 whoami  # which account/org this machine is signed in as
index365 doctor  # diagnose auth, version, and config (--fix applies safe fixes)

Browser (default, recommended): opens your browser, you authorize on the dashboard, and a scoped key is minted and saved locally. No copy/paste, and the secret never travels through a URL.
API key: paste a key you created on the dashboard API Keys page (available on every plan, including Free).

The browser option is a standard loopback + PKCE flow (RFC 8252): the CLI listens on 127.0.0.1, opens the dashboard consent screen, receives a single-use authorization code on the loopback, and exchanges it for the key. The minted key carries the same full agent scope as a dashboard-created key and can be revoked any time from the API Keys page. To skip the menu and go straight to the browser, run index365 login --web.

Get a key manually (CI / headless)

Use any workspace (every plan, including Free), then open your workspace's API Keys page in the dashboard.
Create a key. Every key carries the full agent scope, so it can run audits and manage projects out of the box.
Copy the secret at creation, or re-reveal it any time from the dashboard API Keys page. Keys are stored encrypted (and hashed for lookup); the list view shows a masked i365_ prefix and suffix.

For non-interactive use, pass index365 login --key <your i365_ key> or set INDEX365_API_KEY so no prompt and no browser are needed.

Make an authenticated request

Send the key in the Authorization header. Query-string tokens are rejected by design. GET /api/v1/me works with any valid key and is the right first call.

curl -s https://index365.co/api/v1/me \
  -H "Authorization: Bearer i365_..."

The response returns your organization, the scopes on the key, and the contract version, so an agent can confirm what it is allowed to do before it acts.

Scopes

Every key carries the full scope set: index365 is built for AI agents that operate the whole audit work area, so a key can run audits and manage projects out of the box. Keys cannot touch account or billing data, which stays in the dashboard. The table below is the reference for what each scope grants. What bounds a key is its organization (every request is org-scoped server-side), instant revocation, the per-request audit log, and per-key rate limiting.

Scope	Grants
`projects:read`, `runs:read`, `findings:read`, `reports:read`	Read access to projects, runs, findings, and reports. Included in every key.
`runs:write`	Start audits. Spends organization credits, so grant it deliberately.
`projects:write`, `projects:delete`	Create and update projects, archive projects after echoing the exact domain as `confirm`, and restore archived projects. Archive is reversible and preserves the project's scan history and API keys.

Operate the whole tool

Every key is full scope by design, so an agent can run audits and apply fixes immediately. Keep a separate key per integration and revoke any of them instantly, without affecting the others.

Security model

Key secrets are stored encrypted at rest plus a sha256 hash for lookup, so the dashboard can re-reveal a key on demand while authentication stays constant-time.
Every request is scoped to the key's organization server-side. Object ids from other organizations return 404, not 403, so existence never leaks.
Every key carries the full scope set; the org boundary, instant revocation, and the audit log are the controls.
Every API request lands in an audit log with method, path, and status.
Per-key rate limiting applies; a 429 includes Retry-After.