Reference
API
The REST surface, how it authenticates, and the two transports it accepts.
Every screen in the product is built on the same REST endpoints, which are available to you. There is one authorisation model regardless of how you authenticate.
Two transports, one context
An endpoint accepts either a browser session or a bearer token, resolves the same context either way, and applies the same permission checks. That is why every route serves a mobile client without being modified.
- Access tokens
- Carry the organisation list and last an hour.
- Refresh tokens
- Carry only a user identifier and rebuild the organisation list from the database, which is where revocation gets its chance to apply.
- The active organisation
- Sent as a header and validated against the token, exactly as the cookie is. It is caller input and proves nothing on its own.
Requesting with a bearer token
curl https://your-instance/api/workers \
-H "Authorization: Bearer <access token>" \
-H "x-ergira-org: <organisation id>"Conventions
- The organisation is taken from your authenticated context, never from a query parameter.
- Identifiers in a request body are re-verified against your organisation before use.
- Errors return a status and a message intended to be read by a person.
- Provisioning has its own surface with its own conventions — see Directory provisioning.
One thing the API deliberately does not accept
Backlog position. Reordering names the neighbouring items rather than sending a computed rank, because the server owns what a drop means — and a client computing its own value would eventually break the ordering in a way that looks like a drag silently doing nothing.