Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.rootprint.io/llms.txt

Use this file to discover all available pages before exploring further.

The Rootprint API is the HTTP surface behind your self-hosted instance. Start with the external APIs when you need to send logs from a shipper or query logs from another tool. Use the session-based APIs when you need to automate web-app workflows such as index management, user administration, or monitoring. If you are setting up log collection for the first time, start with Send logs. If you already know the endpoint you need, use the generated endpoint reference in the sidebar.

Send logs

Choose OTLP or the NDJSON gateway and create the right ingest API key.

NDJSON ingest

Push newline-delimited JSON logs through Rootprint to Quickwit.

Search API

Query logs from external tools with a search API key.

​
Base URL

All API requests go to your Rootprint instance. Replace the host below with your deployment URL. 
https://logs.example.com

​
Authentication

Rootprint uses three authentication modes, depending on the endpoint.
Use caseAuth methodWhere to get it
Send logs over NDJSON or OTLPIngest API key (bearer)Settings → API keys
Search logs from an external toolSearch API key (bearer)Settings → API keys
Manage indexes, users, settings, UI dataBetter Auth session cookieSign in through the Rootprint web app
Check healthNoneGET /api/health is public
Bearer-token endpoints use the standard Authorization header. 
Authorization: Bearer <token>
Ingest and search API keys are scoped to one index. The key decides which index the request can write to or read from.
App and admin endpoints are primarily intended for the Rootprint web UI. They are documented so the contract is visible, but automation should prefer API-key-based ingest and search where possible.

​
Endpoint groups

The generated endpoint reference is arranged around the audience for each endpoint.
GroupWhat it contains
Log ingest APINDJSON and OTLP endpoints for log producers
Search APIThe API-key-authenticated endpoint for external log search
Log explorer APISession-based search, histograms, field values, exports, shares, and saved queries
Index management APIIndex metadata, field discovery, sources, preferences, and stats
API keysCreate, inspect, and delete ingest and search API keys
User and invite APIUsers, roles, password resets, invites, and invite acceptance
Authentication APISetup, sign-in, sessions, sign-out, and password changes
Auth settings APIGoogle authentication credentials and allowed domains
System monitoring APIHealth, cluster overview, activity, and metrics

​
Common content types

Use application/json for most app and admin endpoints. Use application/x-ndjson for the NDJSON gateway. 
Content-Type: application/x-ndjson
Use application/x-protobuf for OTLP logs. 
Content-Type: application/x-protobuf

​
Good first requests

GoalEndpointNotes
Health checkGET /api/healthNo authentication required
Send NDJSON logsPOST /api/ingest/ndjsonRequires an ingest API key
Send OTLP logsPOST /v1/logsRequires an ingest API key and protobuf body
Search logsGET /api/search/logsRequires a search API key

​
Error responses

Most app-level endpoints return JSON errors with a stable error object. 
{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "Request validation failed",
    "statusCode": 400,
    "requestId": "req_abc123"
  }
}
StatusMeaning
400Invalid query string, path parameter, or JSON body
401Missing session or bearer token
403Authenticated, but not allowed
404Unknown route or resource
409Conflict, such as first-admin setup already done
413Payload too large
415Unsupported media type
422Unprocessable entity, such as a share payload over 64KB
429Upstream rate limit
500Internal server error
503Quickwit or another upstream dependency is down
OTLP endpoints follow OTLP-style error responses instead of the app JSON error shape.

​
Playground notes

The generated endpoint pages include an interactive playground. For token-based endpoints, paste the token value into the bearer auth field. For session-cookie endpoints, use the playground against a Rootprint instance where you are signed in, or treat the page as a contract reference instead of an interactive client.
Rootprint does not apply an application-level rate limit to ingest endpoints. Apply rate limiting at your reverse proxy or load balancer if your deployment needs it.