Sloose support
API reference
Sloose API 0.72.0
Section titled “Sloose API 0.72.0”The API behind Sloose — AI-assisted data import. The widget, the SDK CLI, an agent over MCP and any client you write all speak to this one surface, so a rule the widget honours and the API does not is not a rule.
Authentication
Send Authorization: Bearer <token>. Two kinds of bearer are accepted on every organisation route: a session JWT
from Login with Zoho, and an organisation API token (slo_…) for the CLI and CI. Both resolve to the same session;
GET /auth/me reports which one you used in via. A handful of routes — minting and revoking tokens,
refreshing a session — are session only and refuse an API token with 403 SESSION_REQUIRED.
Every /orgs/{org}/… route also checks that {org} is the organisation the bearer was issued for. A token for one organisation
can never read another, whatever its role. Roles are ranked operator < builder < admin < owner.
Errors
Refusals are JSON: { "error": "...", "code": "..." }, sometimes with extra fields (issues on a validation
failure, template on a save conflict, balance on an exhausted credit balance). Limit and status refusals use
a closed set of reason codes — see the ReasonCode schema — because the widget switches on them.
Versioning
This document is generated from the running route definitions and committed to the repository, so a change to
the API is a change to a reviewed file. Its version is the version of the shared contract it was generated
against: the same contract that GET /health reports for a deployment. That version moves whenever the
shared schemas and types change; a route can change shape between versions, and this document says how.
Authentication
Section titled “Authentication”sessionAuth
Section titled “sessionAuth”The session token issued by signing in. Lasts thirty days from its last use (eight hours for a Sloose staff member). Using it on this API extends it, at most once a quarter hour; Better Auth’s own get-session extends nothing.
Security scheme type: http
Bearer format: JWT
apiTokenAuth
Section titled “apiTokenAuth”An organisation API token (slo_…) minted by an admin at POST /orgs/{org}/tokens. Scoped to one organisation, acts as the member who created it, never expires unless given an expiry. Routes marked session only refuse it with 403 SESSION_REQUIRED.
Security scheme type: http
adminToken
Section titled “adminToken”The shared backoffice ADMIN_TOKEN, for scripts and CI. Backoffice routes also accept the session of a person with the staff role; the token is never issued to a customer.
Security scheme type: http