LapsHub Live

LapsHub Streaming Protocol

The named contract for LapsHub Live. Organization → track → car → session. Live telemetry plus low-latency onboard. Live API is how you build on it. Hosted Pit Wall is the optional first-party UI on this same protocol.

Org-scoped · Design partners · Specs before runtime

What LSP is

LapsHub Streaming Protocol is the language of the racetrack stream. Not a new binary format. Teams, streamers, and integrators speak LSP; Live API adds sessions, stream access, and meters on top.

Organization
  └── Track (subscribe: all org cars on this circuit)
        └── Car
              └── Session
                    ├── Telemetry events
                    └── Stage (onboard) → publish / watch access

Contract

LSP names org, track, car, session, telemetry events, and onboard stage. Subscribe to a circuit in your organization. Many cars publish. Your product receives those cars as events.

Not a generic bus

Kafka or raw IoT move bytes. They do not name which org, track, car, or session is live, or when onboard should open. That mapping is LSP.

Live API

What you buy to build: session control, stream access, and usage meters. You own the pit wall, overlay, series app, or stream.

Hosted Pit Wall

Optional first-party UI on the same protocol. Prefer a turnkey screen? Same Live backend, hosted pit wall path.

Device integration over MQTT

Connect your telemetry source over MQTT. Open a session in GraphQL, mint short-lived credentials, then publish JSON envelopes from your device, logger, or bridge.

1

Open a session

Call createLiveSession with your org carId and trackId. One live session per car on circuit.

2

Mint MQTT credentials

Call createTelemetryCredentials with role: PUBLISH. Live API returns endpoint, clientId, topicPublish, and expiresAt.

3

Connect and publish

Your device connects to mqtts://live-mqtt.lapshub.com:8883 over TLS and publishes telemetry envelopes to topicPublish. Batch up to 50 points per message.

Supported sources

LapsHub device, RaceBox via your bridge, CAN/GPS loggers, or any stack that can run an MQTT client and emit JSON.

Wire format

JSON over MQTT, application/json. Required envelope fields: v, orgId, trackId, carId, and points[] with at least ts. Optional per point: lat, lon, speedMps, headingDeg, lap, and named channels scalars (rpm, throttle, and so on).

Org-scoped only

Your organization's cars on your circuits. Not a tap into public LapsHub driver-app traffic.

Session + publish credentials (GraphQL)
mutation {
  createLiveSession(input: { carId: "car_42", trackId: "track_ra" }) {
    id
    status
  }
}

mutation {
  createTelemetryCredentials(
    sessionId: "sess_1"
    input: { role: PUBLISH, ttlSeconds: 3600 }
  ) {
    endpoint
    clientId
    topicPublish
    expiresAt
  }
}
Credential response (illustrative)
{
  "endpoint": "mqtts://live-mqtt.lapshub.com:8883",
  "clientId": "lh_org_1_car_42_sess_1",
  "topicPublish": "live/org_1/track_ra/car_42/telemetry",
  "expiresAt": "2026-08-17T19:00:00.000Z"
}

Planned broker: mqtts://live-mqtt.lapshub.com:8883 (Preview, not live). Credentials are short-lived: refresh before expiry. HTTPS batch ingest is a secondary escape hatch when a device cannot run MQTT. Prefer MQTT for high-Hz GPS and CAN channels. Full schema: asyncapi-telemetry-v1.yaml.

Track subscribe

Subscribe to a circuit in your org. Cars you publish send events onto that track stream in real time. Mint subscribe credentials with role: SUBSCRIBE or BOTH on createTelemetryCredentials.

Track topics (illustrative)
Subscribe (your org, one circuit):
live/{orgId}/{trackId}/+/telemetry

Publish (one car):
live/{orgId}/{trackId}/{carId}/telemetry

Live API issues short-lived publish and subscribe access. Batch HTTPS remains a secondary escape hatch when a stream client is not available.

Event JSON example

One envelope, one or more points. Schema version v: 1. Full field list for design partners: asyncapi-telemetry-v1.yaml.

Telemetry envelope
{
  "v": 1,
  "orgId": "org_1",
  "trackId": "track_ra",
  "carId": "car_42",
  "sessionId": "sess_1",
  "points": [
    {
      "ts": "2026-08-17T18:00:00.000Z",
      "lat": 43.798,
      "lon": -87.992,
      "speedMps": 42.1,
      "headingDeg": 187.2,
      "lap": 3,
      "channels": { "rpm": 6120, "throttle": 0.82 }
    }
  ]
}

Telemetry stream

High-Hz car data rides MQTT, not the control API. Devices publish to a car topic; pit walls and overlays subscribe to the track wildcard. See device integration for the connect-and-publish flow.

Publish

Cars or loggers publish to live/{orgId}/{trackId}/{carId}/telemetry.

Subscribe

Pit walls, overlays, and stream stacks subscribe to live/{orgId}/{trackId}/+/telemetry and receive every org car on that circuit.

Not the control plane

Do not push high-Hz GPS points through session APIs. Those calls open sessions and access. The stream carries the points.

Control plane

Live API is how you open sessions, grant stream and watch access, and read usage. The protocol names what those calls mean. Wire-level shapes stay in design-partner review.

Sessions

Open and close a live session for a car on a track in your org.

Access

Short-lived publish, subscribe, and watch access. Open watch access only while someone is watching.

Usage

Meters report publish time, watch time, and accepted telemetry volume.

GraphQL control (not the data plane)
mutation {
  createLiveSession(input: { carId: "car_42", trackId: "track_ra" }) {
    id
    status
  }
}
MQTT track subscribe
Subscribe (your org, one circuit):
live/{orgId}/{trackId}/+/telemetry

Publish (one car):
live/{orgId}/{trackId}/{carId}/telemetry

GraphQL opens sessions and stages. MQTT carries live car data. WebRTC carries onboard. GraphQL is not the live GPS bus.

Video stages

Low-latency onboard for your audience (sub-2-second target). Open a stage only while someone is watching, then feed YouTube, Twitch, TV, or in-venue screens from your own stack.

Publish

Start a stage for the car/session and send onboard from the camera.

Watch

Watch access is short-lived and billable. Open it only while someone is watching.

Your distribution

We run the live backend. You own how the event reaches YouTube, Twitch, TV, overlays, and in-house streams.

Meters

What we count for usage. Pilot pricing is set with design partners.

video.publisher

Participant-seconds while a publisher is connected.

video.subscriber

Participant-seconds while a viewer stays connected.

telemetry.message

Count of accepted telemetry events or batch items.

Design partner specs

These contracts are for architecture review with design partners. Runtime endpoints are not generally available yet. Specs may change before launch.

See LSP in your stack

Request design-partner access. Tell us about your product, stream, or pit wall and we will map sessions, telemetry, and onboard stages to your roadmap.

Design-partner program. Prefer a turnkey screen? Hosted Pit Wall. Looking for the driver app? Download Free.