People sign in once, everywhere
Staff, tenants, landlords, contractors and the mobile apps all sign in through one SortX sign-in service atauth.sortx.co.uk. The staff app, the portals, the API and the MCP server all trust
that service, so a person’s role and workspace are checked the same way whichever surface they
use. Sign-up is closed: people join a workspace by invitation.
Integrations do not use a person’s sign-in. They use an API key.
Create an API key
Only a workspace owner can create or revoke keys.1
Open Settings → API keys
In the staff app, go to Settings → Automation and integrations → API keys.
2
Name the key and choose its permissions
Give each integration its own key. Tick only the permissions it needs (see
Scopes) and choose when it expires: 7, 30, 90 or 365 days.
3
Copy it now
The key is shown once. Store it in your integration’s secret store. If you lose it, revoke
it and create another.
Send the key
Send the key in thex-api-key header. A key belongs to one workspace, so nothing else is
needed:
X-Tenant: <workspace-slug>. If you do, it must be the key’s own workspace,
or the request is refused. This guards against a key being used against the wrong workspace by
mistake.
Do not send a key as Authorization: Bearer <key>. A bearer token is a signed-in person’s
session (it is how the SortX apps call the API, always with X-Tenant), so a key sent there is
refused.
Scopes
Every endpoint belongs to a group, and every key permission is<group>:read (GET requests) or
<group>:write (everything else). A key without the scope for an endpoint gets a 403. The
settings page lists the groups you can grant; the API reference
shows each endpoint’s group.
Some things a key can never do, whatever its scopes, because they belong to the owner as a
person: create or revoke other keys, change workspace settings, or change billing.
Limits
Each key has a fair-use request budget. When it is spent the API answers429 with a
Retry-After header (and retryAfterSeconds in the body). Wait that long and retry.