The public surface
First Six is not a general-purpose API product. The integration surface is small and purposeful: get your people in, and let them sign in. Everything else is handled inside the apps over a row-level-security-protected database, not a public REST API.
What's exposed
| Surface | Direction | Auth | Purpose |
|---|---|---|---|
| OIDC SSO | inbound login | your IdP + PKCE | Authenticate users against your IdP |
| SIS sync | inbound push | bearer shared secret | Provision and update the roster |
| Outbound webhooks | outbound push | HMAC-signed deliveries | Send help-request events (created / crisis / updated / resolved) to your endpoint, configured per tenant in the console |
That is the supported integration surface today. There is no broad public REST API for reading arbitrary records; for event-driven data out, see webhooks.
A narrow surface is a security feature, not a limitation. The less that's exposed, the less there is to misconfigure or leak. The two surfaces that exist are the two every institution actually needs.
Authentication models
There are two, and they are deliberately different:
- User endpoints are authorised by an HttpOnly session cookie minted at SSO login. The browser never holds a readable token; calls are proxied server-side and every read is constrained by row-level securityRow-level security: database policies that filter rows by the caller's identity, so a query only ever returns that caller's permitted rows..
- Machine endpoints (SIS sync) are authorised by a bearer shared secret and run with elevated privileges server-side. They check the secret before anything else, so they never depend on a user session.
Rate limits
Machine endpoints are rate limited per IP. SIS sync allows 20 requests per minute;
a 429 carries a Retry-After header. Build retry-with-backoff into any
automated caller.
The SIS sync secret authorises writes to your roster. Store it in a secret manager, never in source control, and rotate it if it may have been exposed.
Reading data out
Because there is no public read API, getting bulk data out today means the in-console CSV exports (for staff), with webhooks covering event-driven data. If you need a scheduled export, or a programmatic read is on your roadmap, tell us the shape you need so we can prioritise it correctly; it isn't built yet.
Common questions
Is there an OpenAPI/Swagger spec?
Not for a broad API, because there isn't one. The two surfaces (SSO, SIS sync) are documented on their own pages with request/response shapes.
Can we get an API key for read access?
No general read key is issued. User access is via SSO; bulk extraction is via the in-console CSV exports, with webhooks for event-driven data. If you need a scheduled export, raise it with us; it isn't built yet.
What's the base URL?
The integration endpoints live under the console host, e.g.
https://console.firstsix.com.au/api/.... We confirm the exact host during
onboarding.
Related
The fastest answer is usually one question away.