Endpoint groups
Need per-route details? Use API Endpoint Reference.
| Group |
Read endpoint(s) |
Write endpoint(s) |
Primary purpose |
| Status + mode |
GET /api/status |
POST /api/mode, POST /api/settings |
Global runtime state and top-level controls |
| Curves |
GET /api/curve/speed|throttle|rpm |
POST /api/curve/speed|throttle|rpm |
Dynamic mode tuning data |
| Map |
GET /api/map, GET /api/maps |
POST /api/map, /api/maps/* |
2D map editing and file management |
| CAN diagnostics |
GET /api/canview* |
POST /api/canview/capture |
Frame and decoded inspection plus capture-mode state |
| Logs |
GET /api/logs* |
POST /api/logs/delete, /api/logs/clear |
Operational forensics and cleanup |
| Network/OTA |
GET /api/wifi, /api/network, /api/update |
POST /api/wifi, /api/update/*, /ota/update |
Connectivity and firmware update control |
Frontend implementation rules
- Boot each page from
GET /api/status whenever practical.
- Use explicit save/write actions, not optimistic hidden writes.
- After any write, re-read status and reconcile UI from firmware response.
- Treat local storage as convenience cache only.
- Show transport errors and preserve unsaved draft values in UI.
- Do not replicate firmware calculation logic in frontend.
Critical payload contract details
/api/settings
- Single mutation endpoint for many runtime controls.
- Includes
inputMappings, generation, gates, logging toggles, and disengage speeds.
- Can return
debugCaptureActive and forced-state behavior when diagnostics profile is active.
/api/status
- Contains merged runtime view: mode, telemetry, CAN state, mappings, logging, frame diagnostics.
- Use as canonical read model for UI display and verification.
Curve/map validation responsibility
- Frontend should validate obvious shape errors for UX quality.
- Firmware still validates ranges/order and rejects malformed payloads.
Error handling model
- Error response format uses JSON
error message.
- HTTP status indicates category: bad input, not found, or runtime failure.
- For failed writes, do not silently roll UI to assumed new state.
- Prefer inline status banners plus actionable retry steps.
Custom UI compatibility checklist
- Implements required setup mapping flow for speed/throttle/rpm.
- Respects mode semantics and does not alias behavior incorrectly.
- Exposes safety gates and mode-specific disengage settings.
- Supports logs and CAN view endpoints for supportability.
- Handles debug-capture forced-stock behavior gracefully.
Try the OpenHaldex Firmware Demo
Preview the real OpenHaldex firmware UI in your browser with simulated live CAN traffic and interactive pages for tuning, diagnostics, logs, setup, and OTA workflows.
Open firmware demo