Track API

Real-time usage tracking for CLI and integrations. This is the control-plane meter, not a general product analytics bus.

Truth note (bs-8328): Request bodies use type + optional count/metadata. Older docs that showed free-form event/properties objects were wrong and have been removed. Batched telemetry uses POST /api/v1/events/batch.

Endpoints

MethodEndpointDescription
POST/api/v1/trackRecord a usage event immediately
POST/api/v1/events/batchBatch telemetry events (CLI)

There is no GET /v1/track/events list route on the public control plane.

Track usage event

Loading code block...

Headers

HeaderRequiredDescription
Authorization: Bearer bs_… or X-API-KeyYesAPI key with write scope
X-Project-IdRecommendedProject context for attribution

Request body

FieldTypeRequiredDescription
typestringYesOne of the usage types below
countnumberNoDefaults to 1, clamped to 1–100
metadataobjectNoFree-form metadata (not stored as product analytics)

Valid type values

TypeMeaning
api_callsGeneric API usage
agents_invokedAgent invocation
skills_accessedSkill/pattern access
workflows_startedWorkflow start
mcp_callsMCP tool call

Example

Loading code block...

Response

Loading code block...

Batch telemetry

Loading code block...

Used by the CLI to ship buffered telemetry. Events map into the same usage types:

Event nameMaps to usage type
agent.invoked / agent.invokeagents_invoked
skill.accessed / skill.search / skill.viewskills_accessed
workflow.started / workflow.startworkflows_started
mcp.tool.call / mcp.callmcp_calls
api.callapi_calls

Example shape

Loading code block...

Integration notes

  • Prefer the CLI/MCP for agent work; they already emit usage telemetry.
  • Typed SDKs (@bootspring/sdk, Python, Go) are roadmap-only — use curl, fetch, CLI, or MCP.
  • Do not invent client wrappers that are not published on npm.