Distance and Weight are
already exposed as { value, unit } objects — every time-valued field on the
drive-time endpoint is now a Duration object. The inline …Minutes floats
are gone.
Field semantics, computation, and rounding are unchanged — only the wrapper
changes. See the full schema at
GET /api/assets/{assetIdentifier}/drive-time.
Duration schema{ "value": 75.00, "unit": "min" }
unit for drive-time is always "min" today. The full Duration enum is
[ ms, s, min, h ] — always read .unit instead of assuming. value is a
floating-point number rounded to two decimal places — same precision as
before.
currentActivity
durationMinutes → duration (nullable Duration)capacities.<bucket> (for nextDrive, dailyDrive, weeklyDrive,
biWeeklyDrive, weeklyWork)
remaining — now a Duration (was a bare number)limit — now a Duration (was a bare number)remainingInPercent — unchangedshiftWindow
remainingShiftMinutes → remainingShift (Duration)restCompensationOwedMinutes → restCompensationOwed (Duration)nextDailyRestRequiredMinutes → nextDailyRestRequired (Duration)nextWeeklyRestRequiredMinutes → nextWeeklyRestRequired (Duration)nightWorkDurationTodayMinutes → nightWorkDurationToday (Duration)budgets is not affected — its remaining and limit are counts of
permitted uses, not time, and remain plain integers.
Before:
"shiftWindow": {
"remainingShiftMinutes": 496.00,
"nextDailyRestRequiredMinutes": 660.00
}
After:
"shiftWindow": {
"remainingShift": { "value": 496.00, "unit": "min" },
"nextDailyRestRequired": { "value": 660.00, "unit": "min" }
}
Duration shape and the new field names listed above when
modelling the response..value rather than the field itself.unit discriminator on Duration rather
than field-name suffixes — it leaves room for future units without
another rename.The full schema is on the endpoint page:
GET /api/assets/{assetIdentifier}/drive-time.
As always, if you have feedback or questions, reach out to us via support.
]]>The response is computed at request time from the freshest data available. Integrators can use it to build live driver-availability views, compliance dashboards, and dispatch decisions without maintaining their own aggregation layer.
vehicleId is the stable key for the vehicle.
driverCardId is the tachograph driver-card identifier resolved at request
time; it is nullable and only present when a card can be resolved.currentActivity — working state, startedAt, and duration.
The state enum covers DRIVING, BREAK, AVAILABLE, WORK, and
NOT_AVAILABLE.capacities — all five regulatory buckets: nextDrive,
dailyDrive, weeklyDrive, biWeeklyDrive, weeklyWork.budgets — extension and rest-reduction allowances:
drivingExtension, dailyRestReduction, weeklyRestReduction.shiftWindow — shift timing and the rest obligations that will
follow it (remainingShift, restCompensationOwed,
nextDailyRestRequired, nextWeeklyRestRequired).dataLineage — which strategy produced the result
(REAL_TIME_TACHO, EXTRAPOLATED_TACHO, DRIVER_STATUS_HISTORY,
VIRTUAL_TACHO), an ordered list of contributions (each with source
type, provider, and coverage window), and an optional backfill block
listing the fields a fallback strategy had to fill in.Enum values are exposed as { code, label } or
{ code, label, description } objects. code is stable and safe to
switch on; label and description are presentation-only.
Time-valued fields are Duration objects of the shape { value, unit }.
unit is currently always "min" and value is a floating-point
number rounded to two decimal places.
.code, never off .label or
.description (which may change).vehicleId as the stable identifier and treat driverCardId as
optional context — handle null.dataLineage.strategy together with dataLineage.backfill to
understand the confidence and provenance of each result.See the full schema on the endpoint page:
GET /api/assets/{assetIdentifier}/drive-time.
As always, if you have feedback or questions, reach out to us via support.
]]>This update gives integrations a dedicated listing endpoint for tour-level tracking workflows.
We added a new endpoint:
The endpoint returns paginated tour tracking records and supports standard paging parameters.
As always, if you have feedback or questions, reach out to us via support.
]]>This endpoint enables integrations to access tracking-based emissions in a consistent, structured format.
We added a new endpoint:
The endpoint provides CO2 emission report data for a selected tour tracking, including detailed emission structures used in API 2.0.
As always, if you have feedback or questions, reach out to us via support.
]]>This update helps teams consume operational drive-time information directly from the API without building custom aggregation layers.
We added a new endpoint:
The endpoint returns driver working state and drive-time capacities such as next, daily, and weekly remaining limits.
As always, if you have feedback or questions, reach out to us via support.
]]>This update simplifies integrations that need enriched asset metadata for analytics, planning, and operational decisions.
We added a new endpoint:
The endpoint returns available characteristics for a selected asset, including characteristic values and metadata provided by the source system.
As always, if you have feedback or questions, reach out to us via support.
]]>This update makes it easier to track exactly which assets were processed and what their current offboarding status is.
We added a new endpoint:
The endpoint returns detailed status entries for assets included in a specific offboarding request.
As always, if you have feedback or questions, reach out to us via support.
]]>This release is the result of extensive feedback, evolving best practices, and our commitment to long-term stability and clarity for developers.
We've introduced several new endpoints to expand the functionality and reduce the need for workarounds in your integration.
Operation links:
We’ve refactored the underlying data structure to follow a consistent schema across all resources. This ensures predictable response shapes and cleaner code for clients. Key improvements:
API 2.0 comes with completely revamped documentation that is easier to navigate, searchable, and full of practical examples.
Highlights:
We now use the Api-Version HTTP header to manage API versions. This enables us to ship changes
without breaking existing clients.
Example:
Api-Version: 2.0
Read more in our versioning & deprecation policy.
We now formally publish our API End-of-Life (EOL) policy:
We’re committed to providing a stable, scalable, and delightful developer experience. API 2.0 is a big step forward, and we can’t wait to see what you build with it.
As always, if you have feedback or questions, reach out to us via support.
Happy building! 🚀
]]>