Authentication

Base URL: https://api.sloose.com.

Send your bearer on every request:

Authorization: Bearer <token>

Two kinds of bearer are accepted. Most organisation routes take either; the exceptions are the session-only routes listed below.

Session tokens

Issued by signing in — with an emailed link or the six-digit code in the same email, with Zoho, or with a passkey — and bound to one person. A session opens in the organisation the person was last in, or in none; choosing an organisation moves it. Opening the Sloose tab in a CRM does not: when the person is a member of an organisation holding that CRM, the tab is given a session of its own in that organisation (tabToken, from POST /auth/session/frame), which it uses from then on and which ends when the session it came from does — so two CRM tabs of two organisations’ CRMs, open in one browser, each keep working. Otherwise the tab offers the organisations they administer. A session lasts thirty days from its last use (eight hours for Sloose staff), and using it extends it, at most once a quarter hour; a tab’s own session slides the one it came from too.

This is what the app uses. A session is a row, not a claim: the member’s role is read from their membership on every request, so a role changed on People takes effect at once, and POST /auth/session/refresh answers what the bearer is now. Nothing about a role comes from the CRM.

Organisation API tokens

A long-lived token (slo_…) minted by an administrator at POST /orgs/{org}/tokens, for the SDK CLI, CI, and anything else that is not a person sitting at a browser.

• Scoped to one organisation, with the admin role — or its creator’s, if that is lower. An owner’s token is an admin, so owner-only actions need an owner signed in.
• Acts as the member who created it, and stops when they leave the organisation.
• Never expires unless you give it an expiry.
• Revocable, and revocation takes effect on its next request.
• The secret is shown once, at creation. The server keeps only a hash, so a lost token is replaced rather than recovered.

A revoked or expired token answers 401 with code set to TOKEN_REVOKED or TOKEN_EXPIRED, so a client can tell “your token was turned off” from “your token is wrong”.

GET /auth/me reports which kind you used, in via.

Routes an API token cannot reach

An API token is an organisation’s, not a person’s. So everything that is about a person takes a session only and answers a token with 403 SESSION_REQUIRED: signing in and out, listing your organisations and choosing one (/auth/orgs, /auth/session/org), the CRM tab’s organisation match (/auth/session/frame), creating an organisation (POST /orgs), accepting an invitation, asking an organisation to let you in (/auth/access-requests), your account and its sessions, and your second factor. Each of those is marked Session only in the API reference.

These organisation routes are session only too, each for its own reason. They are the main ones, not every one: the API reference marks each Session only route as such.

Route	Why
POST /auth/session/refresh	A token that could refresh itself would never expire.
POST /orgs/{org}/tokens	A leaked token must not be able to mint more.
DELETE /orgs/{org}/tokens/{id}	Nor revoke the ones that would catch it.
POST /orgs/{org}/invitations, DELETE …/invitations/{id}	Who is in the organisation is a person’s decision.
POST /orgs/{org}/close	A token must not be able to end the organisation it belongs to.
GET and DELETE /orgs/{org}/consents…	Apps with access are the person’s grants.
POST /auth/impersonation/end	Only a staff session has one to end.
GET /orgs/{org}/access-requests/{id}, POST …/access-requests/{id}/approve	Letting somebody in is a person’s decision, as with an invitation.
POST /orgs/{org}/imports/{id}/socket	A live socket is somebody with the import open, and lives only as long as their session.
PATCH and DELETE /orgs/{org}/members/{userId}	Who holds which role, and who stays, is a person’s decision.
POST /auth/orgs/{org}/connect, PATCH and DELETE /orgs/{org}/connectors/{id}	Managing connections is a person’s: connecting needs somebody at the CRM’s consent screen, and a disconnect stops every import through it. A token still lists and uses them.
POST /orgs/{org}/billing/checkout, …/portal, …/overage, …/trial, …/plan, …/plan/preview, …/plan/start, …/invoice-request, …/low-balance and …/notices/{id}/ack, and DELETE /orgs/{org}/billing/plan/pending	Billing is a person’s to manage. A token still reads the summary and the plans.

The staff routes (/staff/… and every …/admin route) are not an organisation’s at all: they take a staff session or the admin token, and answer an organisation’s API token with 403 ADMIN_REQUIRED. Starting an impersonation (POST /staff/orgs/{orgId}/impersonate) takes a staff session alone — not even the admin token — because nobody would be on the record as the one looking.

Organisation scoping

Every /orgs/{org}/… route checks that {org} is the organisation the bearer was issued for. A token for one organisation can never read another, whatever its role — this is checked on the server, not chosen by the client.

Roles

Ranked, so a route needing builder also accepts admin and owner:

Role	Can
operator	Start imports, and change, run and delete the ones they started; read configuration; read any module’s records through the organisation’s connections, and write them under a run they have authorised.
builder	Everything above, plus change and run any import in the organisation (deleting only their own), and create and edit templates and schedules.
admin	Everything above, plus change, run and delete any import; curate modules, annotate fields, manage libraries and tokens, connect the organisation, manage members and billing.
owner	Everything above, plus start the trial, make another owner, and close the organisation. The person who creates an organisation starts as one.

An import is its starter’s. An operator who opens somebody else’s import can read it and nothing more; a builder can change and run it but not delete it; an administrator or owner can do all three. A request past that is refused 403 NOT_YOURS.

A role is the invitation’s: an administrator chooses it when inviting somebody and can change it later on People. Nothing about a role is read from Zoho — a Zoho sign-in says who you are and no more.

Backoffice

Operator routes under /staff, /billing/admin, /entitlements/admin and /ai/admin take a staff member’s session — past its second factor — or the ADMIN_TOKEN, and never an organisation’s API token. They are not part of the customer-facing contract and are documented in the API reference under Backoffice.

The rest

Everything an API token can do is in the API reference, with each route’s parameters and responses, generated from the API’s own route definitions. Signing in itself is outside it: the endpoints under /auth/ba that a browser signs in through, and the OAuth discovery documents under /.well-known that an MCP client reads.