Overview
HTTP endpoints for runs, jobs, logs, diagnostics, and spend
The StarSling control plane exposes an HTTP API for everything the platform knows about your CI: which runs and jobs executed, why one failed, where the wall-clock went, and what it all cost.
curl -H "Authorization: Bearer $TOKEN" \ "https://runners.starsling.dev/api/runs?org=acme&limit=5"Prefer a terminal to an HTTP client? The sling CLI wraps these same endpoints, adding argument validation, readable tables, and a stable exit-code contract.
Base URL
All endpoints are served from a single origin:
https://runners.starsling.devEvery path in this reference is relative to it, and every path is prefixed with /api.
Conventions
Two things hold across every endpoint:
- Org scoping. Results are scoped to the orgs you belong to. Org-scoped endpoints take
orgas a required parameter (and often an optionalrepo); a resource in an org you cannot see returns404, not403, so the API never confirms that an id exists elsewhere. - Money and time. Costs are US dollars in
*_usdfields. Durations are seconds unless the field name says otherwise, and runner minutes are billed minutes,max(1, ceil(duration / 60s))per job, so a five-second job still costs a minute.
Endpoint groups
Runs and jobs
List and inspect workflow runs, jobs, and their attempts.
Logs
Read job log lines, filtered server-side so you fetch only what matters.
Diagnostics
Deterministic classification of why a job failed, with evidence.
Timing
Decompose CI wall-clock into runner-lifecycle phases.
Usage and billing
Attribute runner minutes and cost; read billing snapshots and invoices.
Identity
Confirm who you are authenticated as and which orgs you can reach.
Before you start
Two pages cover the behaviour shared by every endpoint. Reading them first saves working it out one 400 at a time: