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.
Login step usually takes
<2 seconds, but can rarely take up to
30 seconds due to background negotiations, retries, and initial vehicle data fetching.
Accept step experiences similar delays as
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|
|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
|Vehicle context||Maximum delay|
|smartcharge PLAN:*||2 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.