p24-infra Docs

atrax-no-event-level-infringements-api

4 min read

Playbook: Atrax exposes NO event-level tachograph-infringements API (vendor limitation)

Established 2026-09-29, resolves the research question in #7306. Records — with a live signed API probe and a full grep of Atrax’s own frontend bundle — that Atrax (tronik.atrax4.com) offers no per-violation infringements endpoint returning a timestamp + vehicle/GPS location per breach. Read this before re-opening the “show when and where each tachograph infringement happened” request — the answer is a vendor limitation, not a missing integration.

The request (#7306)

Fleet managers want, for each tachograph infringement, the exact time it occurred and the location (vehicle/driver position at that moment) — not just the daily per-driver counters (extended_driving_periods, shortened_rest_periods) shown today in p24_atrax_drivers_daily (source: n8n atrax-drivers-daily-snapshot off GET /api/rtdrivers).

Conclusion — Atrax has no such endpoint

Two independent lines of evidence, both run live on 2026-09-29 with a real service-account OAuth token (+ X-Request-Hash/X-Timestamp signing per atrax-request-signing.md):

1. Live signed probe — every guessed event-level endpoint 404s

GET/POST against each of these returned 404 (endpoint does not exist), signed correctly:

/api/infringements                 /api/tachograph/events        /api/driver/infringements
/api/violations                    /api/tachograph/infringements /api/drivers/infringements
/api/tachograph/violations         /api/driveractivity           /api/driver/activity
/api/events                        /api/naruszenia               /api/infringements/{driverId}
/api/infringements?driverId=…&start=…&stop=…
/api/tachograph/events?driverId=…&start=…&stop=…

The only tachograph-adjacent endpoint that returned 200 is the already-known aggregate POST /api/statistics/daily/drivers (body {driverIds, startTimeStamp, stopTimeStamp}) — a daily/weekly summary per driver, carrying no per-violation timestamp, vehicle, or GPS field.

2. Frontend bundle grep — no infringement model exists in Atrax’s own UI

Atrax’s web app is an Ember.js SPA; its REST paths are built dynamically from Ember Data model names via pathForType/adapter namespace, so the endpoint set is discoverable by grepping the public JS bundle (assets/j-atrax-*.js, ~14 MB, served unauthenticated — same technique as atrax-request-signing.md). The complete tachograph surface in that bundle is:

Frontend constructWhat it isEvent-level infringements?
namespace:"api/ddd" → multi/queue, pathForType → "tachograph/files"Raw .DDD digital-tachograph file download queueNo — binary regulatory files, not a queryable GPS-tagged event feed
/remote/tachograph/manual/{vehicle,driver}/…, /download/tachograph/…Remote-download control for raw tachograph card/vehicle filesNo
tachographId (report column), hasTachograph (vehicle boolean)A card-ID column and a “vehicle has a tachograph” flagNo

Crucially, there is no infringement / naruszenie model or endpoint at all. Every violation/naruszenia string in the bundle is about something else:

  • Route violations rendered on the map (_addViolationsSegments, route-violation-icon, route-violates-vr, “naruszenia ograniczeń wymiarowych lub wagowych”) — dimensional/weight routing restrictions, not tachograph driving-time breaches.
  • Lock/seal tamper alarms (TAMPERED_STATUS_CHANGED, “Czujnik pojazdu zarejestrował naruszenie”) — physical-security sensor events.
  • An ecodriving display toggle (showViolations) — a UI setting, not a data feed.

Even the raw .DDD path does not satisfy the request: .DDD files are the regulatory digital-tachograph download format (odometer + time records), not a structured feed, and they do not carry GPS position at the moment of an infringement.

What Atrax DOES expose (already consumed)

  • /api/rtdrivers → p24_atrax_drivers_daily — one-row-per-driver realtime snapshot of daily/weekly counters (verified at code level, #7168). No per-violation timestamp/vehicle/GPS.
  • /api/statistics/daily/drivers — daily aggregate summary per driver (consumed by atrax-daily-stats-collector / atrax-ecodriving-daily).
  • /api/rides/summary → p24_ride_events — per-segment ride events that do carry location (address/addressName/location + GPS x/y). This is the only per-event location source in the stack, and it is about rides, not tachograph infringements.

Best-effort “when + where” already exists — and is low-confidence by design

The nightly atrax_tachograph_compliance_daily.py (#7045/#7153/#7168) already infers a vehicle_id + occurred_at + location for each NEW violation by name-joining the driver (first+last name ↔ p24_ride_events.driver_name) and taking a representative DRIVING segment. The result feeds p24_fleet_anomaly_escalations (triaged in the et-operational-platform escalation panel, every row requires_human_review=true). This correlation is explicitly low-confidence: detail->>'vehicle_id_confidence' is inferred (name-join; no stable shared driver id; Polish-character encoding differences unverified) or null (no matching segment). It is a hint, not the true position at the moment of breach.

Decision — do NOT build an approximation without explicit user sign-off

Per #7306 step 5: because Atrax exposes no event-level infringement data, the correct action is to stop at research and document the vendor limitation (this file) rather than ship a fabricated or approximate feature (e.g. guessing infringement location from the vehicle’s current GPS, or presenting the name-join occurred_at/location as authoritative).

Open decision for the fleet manager (requires human confirmation before any UI work): is the existing low-confidence name-join inference in p24_fleet_anomaly_escalations acceptable to surface in manager/reports/driver-compliance — clearly labelled as approximate / best-effort? If yes, that becomes a separate et-operational-platform UI issue that reads the existing escalation rows (no new table, no new n8n workflow, no new Atrax call). If no, there is no data path that satisfies the original request and it should be closed as a vendor limitation.

  • atrax-request-signing.md — X-Request-Hash/X-Timestamp signing + the “grep the vendor’s own JS bundle” discovery technique used here.
  • ../atrax-tachograph-compliance-operations.md — the daily compliance detector and its inferred-vehicle_id/occurred_at correlation.
  • #7304 — a separate issue (missing JAZDA DZIŚ / ZOSTAŁO aggregate fields); not related to this research and not resolved by it.

Graph View