Auth endpoints

All auth endpoints are under https://api.intelligentinference.ai/api. The ones that establish a session set the two cookies described in the overview; the dashboard calls them for you.

POST /auth/register

{"email": "you@company.com", "password": "…", "organization_name": "Acme", "project_name": "Assistant"}

Creates an account and, in one transaction, everything it needs: organization_name and project_name are optional. Omit the organisation and one is created named after the email; give a name that already exists and the account joins that organisation as a member (no second project or budget is created). Only a brand-new organisation gets a default project (named project_name, or Default Project) and a starting balance. Sets both cookies. 409 if the email is taken.

Note The dashboard does not expose email registration; accounts created this way are provisioned by an administrator. Self-serve sign-up is Continue with Google below.

POST /auth/google

{"id_token": "<Google ID token>", "organization_name": "Acme", "project_name": "Assistant"}

Sign in, or sign up, with a Google account. id_token is the credential Google Identity Services returns after the user picks an account; the server verifies it with Google. For an existing account only id_token matters: the names are ignored and the session is set. For an account the platform has never seen, organization_name and project_name are required: with them, the same provisioning as register runs (organisation, project, and Rs 1,000 of credits); without them the request is refused and nothing is created. 401 {"error": "invalid Google token"} if the token does not verify.

The dashboard splits this into two pages: sign in sends the token alone, and if the account is new hands the visitor to sign up with a warning, where the two names are collected and the same call is made again with them.

POST /auth/login

{"email": "you@company.com", "password": "…"}

Sets both cookies. 401 on a bad password, unknown email, or deactivated account. The body carries no token: the session is the cookies.

POST /auth/refresh

No body. Reads i2_refresh_token from the cookie (never from a body or header) and sets a fresh i2_access_token. The refresh token is not rotated; it stays valid until it expires (7 days) or the session is signed out. 401 {"error": "invalid credentials"} when the cookie is missing, expired, blacklisted, or the account has since been deactivated.

POST /auth/logout

No body. Blacklists the refresh token and clears both cookies. Always 200, even if the session had already lapsed.

GET /auth/me

{
  "user_id": "<uuid>",
  "email": "you@company.com",
  "last_login": null,
  "organization": {"org_id": "<uuid>", "org_name": "Acme", "role": "owner"}
}

The session hydrator: the definitive "am I signed in, and as whom". organization is null if the account belongs to no active organisation. The response may carry fields beyond those shown, which are i2's own and carry no meaning for a customer account; read the ones documented here and ignore the rest.

last_login is the time of the previous successful call to this endpoint, and null the first time it ever succeeds for an account. It is stamped by this call rather than by sign-in, so it moves forward every time the endpoint is hit, including twice in one session. Read it as "has this account been here before", not as a record of distinct sign-ins; only the null has a firm meaning, and it can be observed once.