Enode resources like Schedules and Locations have response times of <200ms
. However, vehicle interactions involve various delays and timing characteristics.
Understanding the range of possible timings without diving into vendor-specific causes, helps you account for these factors in your UX design.
Get Vehicles
and List Vehicles
are fast operations since all data is prefetched by Enode and shared from a cache.
On API versions prior to 2023-08-01
it is possible to request a synchronous update where data is fetched directly from the vendor. Such requests have longer response times, sometimes 30 seconds or more, depending on the characteristics of the underlying vendor APIs. From 2023-08-01
onwards this has been replaced by the refresh hintAPI mechanism.
The Login
step usually takes <2 seconds
, but can rarely take up to 30 seconds
due to background negotiations, retries, and initial vehicle data fetching.
The final Accept
step experiences similar delays as List Vehicles
.
Charging commands show significant timing variability among vendors. Initiating the action is instant, but the updated charging state typically takes 20 seconds to appear, with a maximum delay of 30 minutes.
Command implementation | Typical delay |
---|
native | 3-15 seconds |
synthetic A | 3-30 seconds |
synthetic B | 5-15 minutes |
Webhooks usually involve polling and dynamically adjust the polling rate based on different situations to provide prompt updates without overloading the vehicle.
The maximum baseline delay between a real-world change (e.g., a vehicle being plugged in) and the resulting webhook notification is 7 minutes
.
Vehicle context | Maximum delay |
---|
default | 7 minutes |
charging | 2 minutes |
smartcharge PLAN:* | 2 minutes |
sleeping | 20 minutes |
For faster updates during a short period, call Get Vehicle
. It returns synchronous data from the vehicle and triggers a webhook if anything changes.
For example, when a user expects updates while using your app, you might poll Get Vehicle
every 15 seconds temporarily.