API

The Scout Trails query API gives you read-only HTTP access to the telemetry your organization’s agents send: sessions, individual tool calls, and the rollups behind the dashboard’s trend views (activity, top tools, outlier sessions, model cost, risk flags and external domains). Use it to pull data into your own scripts, notebooks, BI tools or alerting. Every request authenticates with an organization API key, and every response is JSON.

Base URL

https://api.scoutmonitoring.io

All data endpoints live under /v1/ and accept GET only. The service listens on HTTPS (port 443).

Authentication

Send an API key in the Authorization header using the Bearer scheme on every /v1/ request:

Authorization: Bearer wb_api_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The scheme word is case-sensitive: it must be exactly Bearer followed by one space.
Only an API key works here. API keys start with wb_api_. An actor’s ingest key, the credential your coding agents use to send telemetry, is rejected with 401. See API keys.
A key is checked on every request, so a key works the moment it is created and stops working the moment it is revoked.

Check that a key works with /v1/ping:

export TRAILS_API_KEY="wb_api_..."   # the key you copied from the dashboard

curl -s https://api.scoutmonitoring.io/v1/ping \
  -H "Authorization: Bearer $TRAILS_API_KEY"

{"service":"<service name>","version":"0.1.0"}

Quote the header value in shell commands. Without quotes, the space after Bearer splits the header and the request is rejected.

What a key can see

An API key belongs to one organization and reads all of that organization’s telemetry: every actor, every team, every session. It is not limited to the data of the member who created it. When an admin removes that member from the organization, every key they created is revoked. Another organization’s data is never visible through it: asking for another organization’s session or tool call by id returns nothing.

The actor and team filters on the list endpoints narrow results inside your organization. They are filters, not permissions. See Filtering by actor or team.

Conventions

Timestamps

Timestamps in responses are RFC 3339 strings in UTC, for example 2026-09-25T15:27:56.67Z. Timestamps you send in the after and before parameters must also be RFC 3339 with a time zone, for example 2026-09-01T00:00:00Z or 2026-09-01T00:00:00-06:00. URL-encode a + offset as %2B.

Pagination

GET /v1/sessions and GET /v1/tool-calls return pages in a common envelope:

{
  "data": [ ... ],
  "next_cursor": "eyJ0IjoiMjAyNi0wOS0yM1QxNzo1NzowMC4yMTVaIiwiaSI6IjM0MWU2YTkz..."
}

limit sets the page size: an integer from 1 to 500, default 50.
data is always an array; it is [] when nothing matches.
next_cursor is present only when there is another page. Pass it back unchanged as cursor, together with the same filters, to get the next page. When next_cursor is absent you have reached the end.
Treat the cursor as opaque. A malformed cursor is rejected with 400.

curl -s "https://api.scoutmonitoring.io/v1/sessions?limit=100&cursor=$NEXT" \
  -H "Authorization: Bearer $TRAILS_API_KEY"

Errors

Every error from a /v1/ endpoint has the same body:

{"error":{"code":"invalid_request","message":"invalid limit: 501 > 500"}}

Status	`code`	When
`400`	`invalid_request`	A query parameter is malformed or out of range. `message` names the problem.
`401`	`unauthenticated`	The `Authorization` header is missing, is not `Bearer <key>`, or the key is unknown or revoked. The message is always `invalid or missing Bearer credential`.
`404`	`not_found`	The session or tool call you asked for does not exist in your organization.
`500`	`internal`	The query failed on the server. Retry later.
`501`	`not_implemented`	You used the `tag` filter on `/v1/sessions`. Session tags are not supported.
`503`	`keystore_unavailable`	Your key could not be checked because the key store was briefly unreachable. Retry with backoff.

A path that does not exist returns a plain-text 404 page not found, and a method other than GET on a /v1/ path returns 405 Method Not Allowed.

Request limits

A single query runs for at most 30 seconds before the request fails with 500. Narrow the time range or the filters if you hit this. Insight breakdowns return at most 50 rows, and a session detail returns at most 5,000 rows per list.

Health check

GET /healthz needs no key and returns {"status":"ok"} while the service is up. Use it for uptime probes; use /v1/ping to check a key.

In this section

API keys: create, store and revoke the keys the API and the MCP server accept.
API reference: every endpoint with its parameters, response fields and examples.
MCP server: the same data as tools for AI assistants.