canonical: https://jentic.com/apis/enode.io/enode # Enode API Enode is a connectivity platform that abstracts the differences between electric vehicle, charger, and energy hardware brands so applications can read live data and send commands through one consistent API. The Enode API provides OAuth-based access to vehicles, chargers, charging locations, statistics, and webhooks, letting smart-charging and home-energy apps avoid building per-vendor integrations. The spec exposes 28 endpoints covering charging control, location management, fleet-wide statistics, and user authorisation lifecycle. ## For AI agents Read live data from connected EVs and chargers and send charging commands across vehicle and hardware brands through a single OAuth API. ## Scope Does not handle home appliances, grid-scale energy markets, or vehicle purchase data - use for connected EV, charger, and charging-location management only. ## Capabilities - List a user's linked chargers and read live status for a specific charger - Start or stop a charging session on a connected charger by ID - Create, update, and delete charging locations that group home or fleet chargers - Read vehicle telemetry and charging history from linked electric vehicles - Subscribe to webhooks so the app reacts to charging, vendor, and link events in real time - Pull aggregate charging statistics for analytics and reporting dashboards - Revoke a user's vendor authorization to disconnect their hardware from the application ## Use cases ### Smart Home Energy Charging App Build a consumer smart-charging app that links a user's EV and home charger across brands and schedules charging based on tariffs or solar production. The Enode API provides a unified surface across vehicle and charger manufacturers, removing the need to integrate Tesla, BMW, Easee, Wallbox, and others individually. A typical home-charging integration takes a few days end-to-end with Enode versus weeks per vendor. Example prompt: List the user's chargers via GET /chargers, then call POST `/chargers/{chargerId}/charging` to start a session at the cheapest tariff window. ### EV Fleet Monitoring A fleet operator pulls aggregate charging statistics from GET `/statistics/charging` and reads per-vehicle telemetry to optimise duty cycles and forecast electricity costs. Webhooks deliver live charging-state changes so dashboards stay current without polling. Pairs naturally with finance and reporting tools. Example prompt: Call GET `/statistics/charging` with a 30-day window and return total energy delivered and average session length per vehicle. ### User Onboarding and Vendor Linking When a consumer links their hardware, the app uses Enode's OAuth user authorization flow to obtain a user access token, then calls GET /me to confirm the link and DELETE `/me/vendors/{vendor}` when the user wants to disconnect a brand. This mirrors a standard OAuth lifecycle and removes per-vendor SSO work. Example prompt: After a user completes OAuth, call GET /me to confirm the link and surface their connected vendors in the app UI. ### AI Agent Charging Assistant Through Jentic An AI assistant uses Jentic to discover Enode operations by intent and orchestrates charging across a user's vehicles and chargers. The Enode OAuth tokens are kept in your Jentic One instance. The agent can answer questions like 'is my car charging?' or 'start charging now' by chaining list, read, and command endpoints without bespoke wiring. Example prompt: Search Jentic for 'start charging on my home charger', load POST `/chargers/{chargerId}/charging`, and execute it for the user's primary charger. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/chargers` | List chargers linked to the user | | GET | `/chargers/{chargerId}` | Get a charger's current state | | POST | `/chargers/{chargerId}/charging` | Start or stop a charging session | | GET | `/charging-locations` | List charging locations | | POST | `/charging-locations` | Create a charging location | | GET | `/statistics/charging` | Aggregate charging statistics | | GET | `/me` | Inspect the authenticated user and linked vendors | | GET | `/health/vendors` | Check upstream vendor integration health | ## Key resources - **Chargers** — List, read status, and start or stop charging sessions on connected chargers. - **Vehicles** — Read telemetry and charging history from linked electric vehicles. - **Charging Locations** — Create, update, and delete charging locations that group chargers for a user or site. - **Statistics** — Aggregate charging metrics across a user or fleet. - **Webhooks** — Subscribe to real-time charging, vendor, and authorization events. - **User Management** — Inspect the authenticated user, manage linked vendors, and revoke authorization. - **Service Health** — Check the readiness of Enode and the upstream vendor integrations. ## Why Jentic - **Setup:** Wiring Enode by hand means running its OAuth2 flows for both client-credentials and user access tokens, refreshing those tokens, and pointing at the correct link and api host. Through Jentic you install once, import the Enode API from the API Directory, store the OAuth credentials once, and your agent calls it. - **Permission scoping:** Enode puts the charger id in the URL path (`/chargers/{chargerId}/charging`), so a rule can pin your agent to one charger: it can read state and start or stop charging for that charger and nothing else. You choose the operations it may call, so account-level deletes like removing a user or unlinking a vehicle vendor are not included unless you add them. - **Credential handling:** Your Enode client credentials and user access tokens are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'start charging on a connected charger' or 'get charging statistics', and Jentic returns the matching Enode operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Smartcar** — Vehicle-focused unified API for connected cars - **Tesla Fleet API** — First-party Tesla vehicle and charger API - **OpenWeatherMap** — Forecast solar and weather conditions to inform charging schedules ## FAQ ### What authentication does the Enode API use? The Enode API uses OAuth 2.0. A client access token (client credentials grant) covers administrative actions, and a user access token obtained via the authorization code flow covers per-user resources such as chargers and vehicles. Through Jentic, both token types are stored in your Jentic One instance and never enter the agent context. ### Can I start a charging session through the Enode API? Yes. Call POST `/chargers/{chargerId}/charging` with the desired action to start or stop a session on a linked charger. The endpoint abstracts vendor differences across Tesla, BMW, Easee, Wallbox, and other supported brands. ### How do webhooks work with the Enode API? The spec exposes a Webhooks tag with subscription endpoints so your application receives real-time events for charging state changes and vendor link lifecycle. This avoids polling /chargers or /me on a schedule. ### What are the rate limits for the Enode API? The OpenAPI spec does not publish numeric rate limits. The 429 Too Many Requests status is documented and Enode applies plan-based throttling - contact Enode if you need higher sustained throughput. ### How do I read a user's chargers through Jentic? Search Jentic for 'list chargers for an Enode user', load the GET /chargers operation, and execute it with the user access token. Get started with Jentic One, the self-hosted execution layer. ### Does Enode work in production or just test environments? The OpenAPI base URL is the test environment (https://api.test.enode.io/). Enode issues production credentials and a production base URL on request - contact Enode to move from test to production. ### Can I limit what my agent is allowed to do with the Enode API? Yes. Because you run Jentic One yourself, your own rules decide which Enode operations and which stored OAuth credentials the agent may use. Since Enode carries the charger id in the URL path, you can pin the agent to a single charger so it may only read its state and start or stop charging on that charger, for example through GET `/chargers/{chargerId}` and POST `/chargers/{chargerId}/charging.` Account-level operations such as removing a user or unlinking a vehicle vendor stay out of reach unless you explicitly grant them.