Authentication
Use a project API token.
Authorization: Bearer <token>X-Api-Key: <token>
Payload shape
Send nested payloads with an event or check_in root key.
The ingest controller requires an event payload, and the check-in controller requires a check_in payload.
Ingest events
POST application events to the ingest endpoint.
shell
POST /api/v1/ingest_events
Authorization: Bearer <token>
Content-Type: application/jsonjson
{
"event": {
"event_type": "error",
"level": "error",
"message": "NoMethodError in CheckoutService",
"fingerprint": "checkout-nomethoderror",
"occurred_at": "2026-02-14T12:00:00Z",
"context": {
"environment": "production",
"request_id": "abc123",
"metadata": {
"user_id": 42
}
}
}
}For database load metrics from the Ruby gem, metric events typically use message: "db.query" and include timing fields like duration_ms, name, and sql in context.
Check-ins
POST monitor heartbeats for scheduled work.
shell
POST /api/v1/check_ins
Authorization: Bearer <token>
Content-Type: application/jsonjson
{
"check_in": {
"slug": "nightly-reconcile",
"status": "ok",
"expected_interval_seconds": 900,
"environment": "production",
"release": "2026.03.02"
}
}Event types
Use the right event type for the data you are sending.
| Type | Typical use |
|---|---|
error | Unhandled exceptions and captured failures |
transaction | Request timings and method latency |
metric | db.query and custom timing metrics |
log | Structured application logs |
check_in | Heartbeat-style scheduled job reporting |
Transaction events work best when context includes transaction_name, duration_ms, and correlation fields like trace_id or request_id. Log events should carry the same identifiers when available.
Verify delivery
Make sure your first payload shows up where you expect.
Delivery verification
1. Send one test error or transaction payload
2. Open the matching project in Logister
3. Confirm the event appears in the inbox or activity feed
4. Inspect context fields to verify the payload shape
5. Only then add the rest of your instrumentation