Five RLS-scoped read endpoints. API key management in the GM portal. Standard REST. JSON over HTTPS. No competitor publishes an API surface for venue compliance data.
Every endpoint returns data scoped to your venue via Row Level Security at the database layer. Your API key cannot read another venue's data, ever — RLS is enforced server-side, not by the application.
All incidents recorded for your venue. Filter by date range, category (gambling, liquor, welfare, security), severity, and staff member.
Suspicious Matter Report pipeline state — drafts in progress, in review, awaiting CO sign-off, and submitted. AUSTRAC reference numbers included for submitted SMRs.
Append-only audit trail. Every authenticated action — read, write, sign-off, escalation — recorded with actor, timestamp, action, and target. Foundation of the evidence chain.
63 regulatory obligations across 9 jurisdictions, with their current evaluation status, citation references, and linked artifacts (screens, documents, db tables).
Read-only export of the live compliance map — every obligation rendered against the current state of system. The same data the GM portal renders, in JSON.
API keys are managed at /gm/settings/api-keys in the GM portal. Each key is scoped to a single venue (multi-venue groups need one key per venue). Keys can be rotated or revoked at any time without affecting other keys. Authentication is standard bearer-token over HTTPS.
GET /api/v1/incidents? from=2026-04-01& to=2026-04-25& limit=50 authorization: Bearer va_pk_live_abc123... accept: application/json
200 OK
content-type: application/json
{
"data": [
{
"id": "inc_4f2a...",
"occurred_at": "2026-04-25T10:41:00+10:00",
"category": "gambling",
"severity": "medium",
"behaviours": ["distress", "prolonged-play"],
"venue_id": "ven_...",
"staff_id": "stf_..."
}
],
"meta": { "total": 23, "limit": 50 }
}You own your compliance data. The API exists so you can move it, archive it, integrate it with your BI tools, or hand it to a regulator without going through a sales call.
Row Level Security is enforced at the Postgres layer, not by application code. An API key with a venue scope cannot read another venue's data even if the application were compromised.
Write endpoints are deferred to v2. The reasoning: every write path needs careful design around immutability, audit logging, and the four-stage SMR pipeline. We'd rather ship reads right than writes wrong.
v2 is on the roadmap. Targets: write endpoints for incident ingestion (lightweight, idempotent), outbound webhooks for critical events (sanctions hit, inspector arrival, FRT confirmed match), and bulk export for end-of-month and end-of-year reconciliation. Authentication remains key-based; webhook payloads will follow the same HMAC-signed pattern as the FRT receiver.
We don't commit to a date for v2 publicly — we commit to shipping it right. Want to influence the spec? Get in touch.