Reference · built on requestConnectorEnergy, EV & distributed resources

Victron VRM API

Installations, statistics, diagnostics, alarms, and Dynamic ESS settings from the VRM Portal for Victron inverter/chargers and batteries.

Request accessPricing ↗

About

Victron Energy makes inverter/chargers, MPPT solar chargers, batteries, and the GX range that reports each installation to the VRM Portal. The VRM API at vrmapi.victronenergy.com/v2 is that portal's REST interface: installations per user, system overview, diagnostics, statistics by interval, configured alarm rules and their log, GPS and data downloads, tags, and Dynamic ESS configuration. Reports and CSV or XLSX exports moved to the separate vrm-reports-api.

Through Fibric, an operator reads battery state, solar yield, and generator run time across marine, off-grid, and backup installations, then proposes an alarm rule, a settings change, or a Dynamic ESS adjustment for your approval. Each approved write is sent once with a receipt.

This is a reference listing. It documents what Fibric would read from Victron VRM API and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Installations a user can access through /users/{idUser}/installations, plus each installation's system overview and settings
  • Statistics through /installations/{idSite}/stats at 15mins, hours, 2hours, days, weeks, months, or years, with venus, live_feed, consumption, solar_yield, kwh, generator, generator-runtime, custom, and forecast series
  • Diagnostic log records per installation through /installations/{idSite}/diagnostics, paged 100 at a time
  • Configured alarm rules, eligible users, and usable data attributes through /installations/{idSite}/alarms, and the alarm log through /alarm-log
  • GPS and raw data downloads, overall stats, tags, and the Dynamic ESS configuration of an installation

Proposed actions

  • Target capability: propose adding, editing, or deleting an alarm rule through POST, PUT, or DELETE /installations/{idSite}/alarms
  • Target capability: propose clearing an active alarm through POST /installations/{idSite}/clear-alarm, marked as cleared by the user in the event log
  • Target capability: propose installation settings changes through POST /installations/{idSite}/settings, such as the no-data alarm timeout or geofence
  • Target capability: propose a Dynamic ESS configuration update through POST /installations/{idSite}/dynamic-ess-settings
  • Target capability: propose adding or removing installation tags through PUT and DELETE /installations/{idSite}/tags

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Keep a remote battery bank above its floor

    Reading state of charge and solar yield at 15 minute intervals, the operator predicts when an off-grid bank will hit its floor and proposes a generator run or a Dynamic ESS change for approval.

    With Battery Dispatch, Fuel Reserve

  • Standardize alarm rules across a fleet

    The operator compares each installation's configured alarms with your standard set and proposes the missing rules, one installation at a time, for you to approve.

    With Alarm Triage, Sensor Health

  • Schedule generator maintenance from run time

    Generator run-time series accumulate per installation. When a unit crosses its service interval, the operator drafts the maintenance task with the hours attached.

    With Generator Test, Predictive Maintenance

Requirements

  • A VRM user account with access to each installation, since endpoints are restricted to users who can open the installation
  • An access token created under that user; the API lists token names but never returns a token value again
  • The installation ID for each site, resolved through /users/{idUser}/get-site-id or the installations list
  • For exports and reports, a separate integration with vrm-reports-api at vrm-reports-api.victronenergy.com
Authentication
A VRM access token created for your user through /users/{idUser}/accesstokens/create, sent in the x-authorization header as Token <value>; Bearer tokens are deprecated from 1 June 2026.

Limits

  • Most endpoints share a rolling window of 200 requests, one released every 0.33 seconds, about 3 per second; 429 responses carry Retry-After
  • Stats spans are capped by interval: 31 days at 15mins or hours, 180 days at days, 140 days at weeks, 5 years at years
  • Victron Energy does not offer support for API integrations except by specific arrangement; the Modifications section on Victron Community is the stated route
  • Alarm rules on enums and on numbers use different field casing, and the API warns when the wrong one is sent

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Victron VRM API ↗

Questions and answers

Which token format does the connector use?
An access token in the x-authorization header in the format Token <value>, created through /users/{idUser}/accesstokens/create. Victron documents the Bearer format as deprecated from 1 June 2026 and asks integrators to migrate to access tokens.
How far back can statistics be pulled in one call?
It depends on the interval: 31 days at 15mins or hours, 180 days at days, 140 days at weeks, 24 months at months, and 5 years at years. The connector splits longer histories into successive requests within the rate limit.
Can the connector export energy reports?
Not through this API. Victron moved report generation, including CSV and XLSX exports of energy data and alarm or fault logs across installations, to vrm-reports-api. This listing covers the VRM API itself; a reports integration is scoped separately.
Ask about Victron VRM API

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Victron VRM API through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy