The number one reason for developing API v1.1 is to make it easier for development teams to program with the eDRV API. Here are some highlights
Your application should never have to poll eDRV for new data. v1.1 is fundamentally architected around Webhooks. For example your application is instantly informed when a chargestation disconnects, or when there is a new energy report.
We have significantly expanded searching for resources by it's child parameters. For example searching for Chargestations that have an
Available Connector can now be done in one API call.
All resources now allow the developer to attach meta data. For example when creating a User on eDRV you may want to store their matching user Id from your application. Or you may want to save a Stripe payment Id when starting a new charging Session.
See API Reference]
We introduce a new resource called Sessions that presents the required data for the lifetime of a charging event. For example start and stop charging are directly available in Sessions.
API Responses now include all the relevant data embedded in them so your application does not have to make additional calls to get the complete state of resources. For example any Connector response via an API call or Webhook will embed any attached Rates saving you an extra API call.
v1.1 clarifies the messaging model with eDRV as a Server to Server (M2M) API giving developers direct control on communication via their server side application.
Updated 5 months ago
Let's dive in.