ApexLog

Compares two laps (possibly from different sessions) with a per-sector time delta table computed server-side from GPS telemetry — the cheap way to answer 'where am I losing time'. When the track has sector gates (harvested from the RaceChrono track definition), sectors are timed at real gate-line crossings and sectorCount is ignored; otherwise sectors are equal-distance splits of each lap's GPS distance, not official timing sectors. The response's sectorSource/note say which applied. Lap numbers default to each session's best lap. Positive sector delta means lap B was slower there.

GPS telemetry trace for one lap of a session. Default response is downsampled to roughly one point per 10 m of travelled distance with [timeMs, distanceM, speedKph, lat, lon] per point — compact enough to analyze in-context. Set raw=true only when you genuinely need full resolution and every channel (altitude, g-forces, rpm, and OBD channels such as fuel and temperatures when present); it is much larger. Omit lapNumber to get the session's best lap.

Returns the user's photos for one entity as viewable images (downscaled JPEGs), so wear and condition can be assessed visually — e.g. brake disc lips/scoring or tire surface on a component installation, paddock/car photos on a session, detail shots on a setup, day-level shots like official timing boards on a track day. Returns the newest photos first (default 4, max 10 per call) with a metadata block per photo. Entities with photos are flagged via photoCount in list_vehicles and get_session.

Full context for one session: all laps with times and validity, the complete setup snapshot (tires, pressures, brakes, suspension, alignment, fuel), weather/track conditions, wear state of the tire and brake sets that were installed, session notes, the driver's own point annotations anchored to telemetry moments (e.g. 'blocked by traffic' with the lap it happened on), linked onboard video links (YouTube), and a telemetry availability summary. Use list_sessions first to find the session id. Session, setup, installed components, and the track day each carry a photo count; when > 0, get_photos returns the actual photos as viewable images (day-level photos: scope 'trackday' with trackDayId).

Whole track day in one call: date, track, vehicle, organizer, day-level weather and notes (e.g. official results the driver wrote down), day photo count (get_photos scope 'trackday' returns the images — often timing-board or results screenshots), onboard video links, and a summary of every session that day (lap count, best lap, telemetry availability, photo count). Use the trackDayId from list_sessions or get_session. Drill into one session with get_session for setup, laps and wear context.

Lists the user's track sessions, newest first. Filter by track name (substring match), vehicle id, and/or date range. Each entry has the session id (use with get_session, get_lap_telemetry, compare_laps), the track day id (use with get_track_day and get_photos scope 'trackday'), date, track, vehicle, lap count, best lap time, weather, whether GPS telemetry is available and whether onboard video links exist. The response includes totalMatching and truncated — when truncated is true, re-query with a higher limit (max 100) to see the remaining sessions. When onboarding.state is 'empty_account', explain that the connection is ready and surface both the importUrl and demoUrl actions instead of replying only that no sessions were found.

Lists the user's vehicles with total track mileage, the most recent setup snapshot (tires, pressures, alignment, brakes), and currently installed wear-tracked components (tire sets, brake pads, brake discs) including km/laps accrued and latest tread depth measurements. Each component has a photoCount; when > 0, get_photos(scope='component', id) returns viewable wear photos of that set. When onboarding.state is 'empty_account', explain that the connection is ready and surface both the importUrl and demoUrl actions instead of replying only that no vehicles were found.