Sigtake API#
Real-time alert management & monitoring for ops teams. This reference covers the public ingestion API — the endpoints you use to push data into Sigtake from your own systems:Alerts — send events from any source; duplicates are collapsed automatically and routed to the right team.
Signals — send numeric metric readings; your monitor rules evaluate them continuously and raise alerts when something's off.
The dashboard API (users, teams, channels, etc.) lives behind session auth at app.sigtake.com and is not part of this reference.
Base URL#
All requests are HTTPS and send/receive JSON (Content-Type: application/json).
Authentication#
Every request is authenticated with your team API key, sent in the X-Api-Key header:X-Api-Key: sk_3f2a9c1b4d5e6f7089a1b2c3d4e5f6a7
API keys are created in the dashboard (app.sigtake.com) and shown once at creation — store them securely.
Each key is scoped to one team; data you push is tagged to that team's organization automatically.
A missing, invalid, or disabled key returns 401 Unauthorized.
Keep keys secret. Treat them like passwords — never commit them to source control or expose them in client-side code. If a key leaks, revoke it from the dashboard.
Rate limits#
Two limits apply to every request. Exceeding either returns 429 Too Many Requests.| Scope | Limit |
|---|
| Per organization | 300 requests / minute |
| Per API key | 60 requests / minute (default, configurable per key) |
When rate-limited, back off and retry after a short delay.
Core concepts#
Alerts#
Push an alert with POST /api/ingest. Sigtake fingerprints each alert on source + title + severity:If an open alert with the same fingerprint already exists, its occurrence_count is incremented instead of creating a new row (response meta.is_duplicate: true).
Notifications fire at occurrence thresholds 1, 10, 25, 50, 100 (and every 100 after) — so a flapping alert won't spam your team.
Alerts are routed to a team via team_code, then fanned out to that team's notification channels (email, SMS, Microsoft Teams, in-app).
critical · high · medium · low · info.Signals#
Push numeric readings with POST /api/signals/ingest. Readings target a signal monitor identified by its source key. Rules on that monitor evaluate every minute and raise a real alert (that flows into the same dedup/routing pipeline) when they hold. Rule types:Threshold — avg/min/max/last/sum/count over a time window vs a value.
Anomaly — learns each metric's normal by hour & weekday; alerts on deviation, no threshold to set.
Heartbeat — alerts when a metric stops reporting.
Endpoints#
| Method | Path | Description |
|---|
POST | /api/ingest | Ingest an alert (deduplicated automatically) |
POST | /api/signals/ingest | Ingest a batch of numeric signal readings |
Quick start#
Send an alert#
{
"data": { "id": "9f1c2e7a-3b4d-4c8e-a1b2-c3d4e5f6a7b8", "title": "High CPU on web-01", "status": "firing", "severity": "high", "occurrence_count": 1 },
"meta": { "is_duplicate": false, "occurrence_count": 1 }
}
Send signal readings#
Responses & errors#
Successful requests return 200/201 with a JSON body. Errors return a JSON object with a message or error field.| Status | Meaning |
|---|
200 OK | Signal readings accepted |
201 Created | Alert created or deduplicated into an existing one |
400 Bad Request | Validation error, or unknown team_code (alerts) / invalid body (signals) |
401 Unauthorized | Missing, invalid, or disabled API key |
404 Not Found | No signal monitor matches the given source key |
409 Conflict | The target signal monitor is paused |
422 Unprocessable Entity | Metric cardinality limit reached (50 per monitor); some or all readings rejected |
429 Too Many Requests | Rate limit exceeded — back off and retry |
Support#
Questions or issues? Reach us at help@sigtake.com, or manage your keys, teams, and channels in the dashboard at app.sigtake.com.Modified at 2026-07-21 02:00:15
