API Reference¶
SentriKat provides a comprehensive REST API for all operations.
Two base URLs¶
Most of this reference describes your own installation:
A handful of routes are not on your installation at all. They are on the license server, which is where activation, the heartbeat, releases and the shared knowledge base live:
Those are the ones under /api/v1, and each page that describes them says so:
| Route | What it is for |
|---|---|
POST /api/v1/license/activate | Turning an activation code into a signed license |
POST /api/v1/license/heartbeat | The license check, every 12 hours, licensed installations only |
POST /api/v1/license/telemetry | Reading back what is held about one installation |
POST /api/v1/verify-signed | Verifying a signed payload |
GET /api/v1/releases/latest | The current release |
POST /api/v1/kb/mappings/push | Contributing a mapping |
GET /api/v1/kb/mappings/pull | Receiving the shared mappings |
/api/v1/vuln-feed/* | The vulnerability feed, see Vulnerability Feed API |
Calling one of these on your own instance returns 404, which is the usual first symptom of using the wrong base URL.
The heartbeat carries counters, knowledge-base state, a data-quality index and the last bundle outcome, never product lists, hosts or CVEs. Every field is listed at sentrikat.com/telemetry.
Authentication¶
There is no bearer or JWT token to request, store or refresh. Which mechanism you use depends on who is calling. See Authentication for the full description.
| Caller | Mechanism |
|---|---|
| A person or a script acting as one (products, vulnerabilities, reports, exports, remediation) | Session cookie from /api/auth/login, plus a CSRF token on state-changing requests |
| An agent or an inventory import | X-Agent-Key header |
| A licensed installation talking to the knowledge base or the vulnerability feed | Authorization: Bearer <first 64 characters of the signed license> plus X-Installation-ID |
Signing in as a user¶
Log in once, keep the cookie, and send it with every later call:
# 1. sign in, storing the session cookie
curl -c cookies.txt -X POST https://sentrikat.example.com/api/auth/login \
-H "Content-Type: application/json" \
-d '{"username": "admin", "password": "your-password"}'
# 2. reuse it
curl -b cookies.txt https://sentrikat.example.com/api/products
The login response carries no token: it reports the signed-in user and any next step (password expiry, 2FA setup). The session lives in the cookie.
State-changing calls need the CSRF token too
POST, PUT, PATCH and DELETE additionally require the CSRF token issued with the session, sent as X-CSRFToken. A GET never does. The curl examples in this reference write it as -H "X-CSRFToken: $CSRF".
API Sections¶
-
Authentication
Login, logout, session and agent keys.
-
Products
CRUD operations for software inventory.
-
Vulnerabilities
Query and manage vulnerability matches.
-
Sync
Exploited-vulnerability and exploit-probability synchronization.
-
Agent
Agent inventory submission.
-
Webhooks
Outgoing webhook configuration.
-
KB Sync
Community knowledge base push/pull.
-
Vulnerability Feed
The read-only feed and offline bundle for licensed installations.
Common Patterns¶
Pagination¶
List endpoints support pagination:
Response includes pagination metadata:
Filtering¶
Most list endpoints support filtering:
GET /api/products?vendor=Microsoft&criticality=5
GET /api/vulnerabilities?priority=critical&ransomware=true
Sorting¶
Sort results with sort and order:
Error Handling¶
Errors return appropriate HTTP status codes:
| Code | Meaning |
|---|---|
| 400 | Bad Request - Invalid parameters |
| 401 | Unauthorized - No valid session, agent key, or license credential |
| 403 | Forbidden - Insufficient permissions |
| 404 | Not Found - Resource doesn't exist |
| 429 | Too Many Requests - Rate limited |
| 500 | Server Error - Contact support |
Error response format on your own installation (the license-server routes return {"detail": "..."} instead):
{
"error": "validation_error",
"message": "Invalid vendor name",
"details": {
"field": "vendor",
"constraint": "required"
}
}
Rate Limiting¶
Every endpoint sits under a global default, and the busier ones set their own tighter limit on top of it:
| Scope | Limit |
|---|---|
| Global default, all endpoints | 1000/day and 200/hour |
| Login | 5/minute |
| Password reset, change password | 3/minute |
| Agent inventory | 60/minute |
| Agent heartbeat | 120/minute |
| Agent container scan | 30/minute |
Per-endpoint limits are stated on each API page where they differ from the default.
Rate-limit headers
Responses from your own installation do not carry X-RateLimit-* headers. A request that exceeds a limit returns 429; back off and retry rather than trying to track the remaining budget from the response. The license server's 429 does carry Retry-After.
OpenAPI Specification¶
Interactive API documentation available at:
Download OpenAPI spec: