Read your entire GRC program over HTTPS, and write it back when you choose to allow it. One workspace per key, read by default, write with an explicit read & write grant, and authorized by the same database rules that guard the app.
An API key acts as the user it is bound to: it sees exactly what they see, and it can only change what they could change, nothing more.
No SDK required. A key and curl are enough to read live data from your workspace.
Create a key
In the app, an admin opens Settings ▸ APIand creates a key, binding it to a chosen member and picking its access level: read, or read & write. The key acts as that person, with their live permissions, and stays pinned to that workspace. Copy it once; you will not see it again.
Settings ▸ API ▸ Create key
# Settings ▸ API ▸ Create key csfaas_sk_live_5f3c9a2b7e1d84... # Shown once. Store it in your secrets manager.
Call the API
Send the key as a Bearer token. Start with /v2/me to confirm who the key belongs to and which workspace it reads.
bash
curl https://api.csfaas.com/v2/me \ -H "Authorization: Bearer csfaas_sk_live_..."
Read the response
Plain JSON, scoped to you. Every other endpoint follows the same shape and the same access rules.
200 OK · application/json
{
"user": {
"id": "8f2c...e10",
"name": "Dana Okafor",
"email": "[email protected]"
},
"workspace": {
"id": "ffd5...761",
"name": "Acme Security",
"roles": ["Risk Analyst"]
},
"access": "read"
}There is no privileged path. Your key resolves to a short-lived, workspace-pinned token, and PostgreSQL row-level security decides what it can read and write, exactly as it does for your session in the app.
Your API key
csfaas_sk_live_...
Short-lived JWT
pinned to your workspace
PostgreSQL RLS
scoped to the bound user
Your data
nothing more
The service holds no privileged database credentials. It cannot read or change anything you could not, and it cannot reach another workspace, because the boundary is enforced one layer below the code.
Bound to a user
An admin binds each key to a chosen member, and it acts with that person's live permissions. Change their role and the key follows automatically; there is no god-mode service account.
One workspace per key
Each key is pinned to a single workspace. It can never read across the tenant boundary.
Read by default
Every key starts read-only. Only a key explicitly granted the read & write access level can create, update or delete anything; a write with a read-level key is refused.
Enforced by the database
Every request is authorized by the same PostgreSQL row-level security that guards the app. The API cannot forget a check.
No privileged copy
The service carries no privileged database credentials. It resolves your key, mints a short-lived, workspace-pinned token, and acts as you.
Instant revocation
Revoke a key in Settings and it stops working immediately. No cache, no grace window.
Workspace-auditable
Key use is recorded in your activity log, so an admin can see exactly what was read or changed, and when.
European hosting
The API runs on the same EU-hosted, GDPR-aligned infrastructure as the platform itself.
Browse every path, parameter, schema and response in a full interactive reference, generated from the running service. Download the OpenAPI 3.1 spec right from the reference to drop into Postman, Bruno or your codegen of choice.
Interactive API reference
https://api.csfaas.com/v2 · interactive and always current
Standard HTTP status codes, a JSON body on every error, and one rule that trips up first-time readers.
Empty is a 200, not a 403
A successful call that returns no rows is a normal 200 with an empty data array. Row-level security filters invisible records out; it does not raise. Do not treat an empty list as an error.
Unauthorized
The key is missing, malformed or revoked. Send a valid Bearer token.
Forbidden
The bound user lacks permission for this resource, or a read-level key attempted a write. Access mirrors the app exactly.
Not found
The id does not exist, or it exists but is outside your visibility.
Unprocessable
A query parameter failed validation. The body names the offending field.
Too many requests
You hit the rate limit. Back off and retry after the Retry-After header.
Rate limits
Requests are metered per key. When you exceed the limit you receive a 429 with a Retry-After header. Read in pages and cache what you can; the API is built for steady polling, not bursts.
Build on your program
Create a key in the app, point curl at it, and pull live compliance data in seconds. Grant read & write when you are ready to automate changes. Reads and writes alike are included in every plan, at no extra cost.