Skip to main content
A frame is the JSON wire representation of one telemetry span or log. Live telemetry and retained retrieval use the same tolerant envelope. Telemetry is the product concept; frames are the format you parse when you use the API, SDKs, CLI JSON output, or raw WebSocket. Current producers emit two top-level frame kinds: span and log.

Understand live and retained shapes

The shared schema keeps end_time_unix_nano and status optional because an in-flight live start has neither. Current retained spans contain both fields. Do not assume that every live start will receive an end frame.

Span frames

A completed SDK-call span can look like this:

Span fields

“Required” describes the current shared REST schema. The retained runtime is more specific where noted. status contains required string fields code and message. Current producers use ok and error. A successful span normally has an empty message. Treat new status strings as additive values.

Span types

Current producers use these span_type values: Older retained session roots can use phone_session. Treat it as the older name for the session root. The vocabulary is open: render an unfamiliar value generically instead of rejecting the frame.

Log frames

An output log can look like this:

Log fields

Log types

The log_type vocabulary is open. Preserve, render, or ignore an unfamiliar value without failing the rest of the trace.

Reconstruct relationships

All frames for a session share a trace_id. A span’s parent_span_id connects it to its parent. A log’s optional span_id connects it to the span under which it occurred. The common hierarchy is:
file_push and media_capture spans are normally session-level siblings of a run. A workflow-less interactive SDK call can sit directly under the session. Use span_id as the identity when you pair a live start with its end, deduplicate a replay, or join an SDK-call cost map. Use axilio.inference.id to join an inference cost map.

Read common attributes

attributes is an extension point. Producers can add namespaced keys without changing the frame envelope. Raw API and SDK readers can see attributes that the Dashboard does not display. Common cross-cutting keys include: Captured SDK-call input and output can contain sensitive data. See Data controls before storing or redistributing raw attributes.

File and media attributes

These attributes can appear on file_push or media_capture spans: A transfer_progress log uses its span_id to correlate with the file push or media capture and can contain: Attributes are not all required on every phase. Do not reject a frame because an activity-specific attribute is absent.

Build a tolerant reader

For every interface:
  • Accept unknown fields within a known frame.
  • Treat new span_type, log_type, severity, status, and attribute values as additive.
  • Preserve or render unknown data when your application needs lossless forwarding.
  • Validate required fields before using them. An omitted known-frame field is malformed even if a generated client model decodes it to a zero value.
  • In the live stream, accept either one frame object or an array of frames.
Top-level kind compatibility currently varies by interface and version: A missing, empty, null, or non-string kind is malformed data, not a future frame kind. Do not describe unknown top-level kinds as universally supported until the reader you deploy has been tested for that behavior.
The generated REST API reference owns the machine-readable operation schema. This page explains field meaning and compatibility across retained and live interfaces.

Next steps

Retrieve telemetry

Retrieve and paginate the retained frame envelope.

Live telemetry

Consume frames and cursor messages while a session is active.

Telemetry dashboard

Turn frame relationships into a useful execution story.

Data controls

Understand sensitive attributes, retention, and access.