Reference · built on requestConnectorEnergy, EV & distributed resources

Zaptec API

Installations, chargers, charger state, and archived sessions from Zaptec Portal, with a service bus, webhooks, and OCPP onboarding.

Request accessPricing ↗

About

Zaptec makes the Go, Go 2, and Pro chargers and runs Zaptec Portal, where an installation is the top-level entity holding one or more chargers. The REST API at api.zaptec.com lists installations and chargers, returns charger state, archives completed sessions with OCMF signatures, and produces installation usage reports. State changes arrive as ChargerState messages over an AMQP 1.0 service bus instead of polling. Session start and session end webhooks let an external system approve or deny a charge. An installation can also be switched into OCPP 1.6J mode, at box level or through Zaptec's cloud, so a third-party management system takes over.

An operator on Fibric watches sessions and charger state and proposes an installation current change or a charger command for your approval.

This is a reference listing. It documents what Fibric would read from Zaptec 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 and the installation hierarchy through GET /api/installation and /api/installation/{id}/hierarchy, including AvailableCurrentMode
  • Chargers and charger state through GET /api/chargers and /api/chargers/{id}/state, with firmware details per installation
  • Archived sessions through GET /api/sessions/archived: energy in kWh, start and end time, authorized user, and offline, voided, aborted, and signed flags
  • Installation usage reports through POST /api/chargehistory/installationreport
  • ChargerState messages (ChargerId, StateId, Timestamp, ValueAsString) over the Azure Service Bus topic for your installation, consumed with AMQP 1.0
  • Session Start URL and Session End URL webhooks, posted when a user starts a session and when the vehicle disconnects

Proposed actions

  • Target capability: propose a new availableCurrent, per-phase currents, or minPowerOfflineMode on an installation through POST /api/installation/{id}/update
  • Target capability: propose a charger command through POST /api/chargers/{id}/sendCommand/{commandId}: RestartCharger (102), PauseStopCharging (506), ResumeCharging (507), DeauthorizeStopCharging (10001)
  • Target capability: propose a session priority change through the Set session priority endpoint
  • Target capability: propose onboarding a charger to OCPP 1.6J and setting its OCPP URL and password through the chargers/{chargerId}/ocpp-settings endpoints
  • Target capability: propose switching an installation between Zaptec mode, OCPP mode, and OCPP cloud mode

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

What you can build

  • Keep the site under its supply limit

    Read charger state and phase currents from the service bus. When the site nears its main-fuse limit, propose a lower availableCurrent on the installation and show who is charging. You approve; the change is logged.

    With Charge Balancing

  • Charge the fleet before the first departure

    Match archived sessions and current charger state against tomorrow's departures. Propose session priorities and resume commands for vehicles that will not be ready in time.

    With Depot Charging

  • Shed EV load during a grid event

    When a demand-response event arrives, propose a temporary availableCurrent cut and the chargers to pause, then the restore once the event ends.

    With Event Response, Peak Demand

  • Bill each session to the right party

    Pull archived sessions with energy, authorized user, and OCMF signature, and propose the monthly charge per user or tenant for review.

    With Utility Chargeback

Requirements

  • A Zaptec Portal account and the Installation ID and Charger ID GUIDs from the portal's settings
  • Owner or Service permission on the installation; maxCurrent changes need Service permission (electrician)
  • For service bus messages, GET /api/userGroups/{usergroupId}/messagingConnectionDetails as an installation owner, queried again before each connect
  • For session webhooks, Webhook Authentication selected on the installation's Authentication tab, with an OAuth bearer or HTTP Basic credential
Authentication
OAuth 2.0 password grant against https://api.zaptec.com/oauth/token with a service account's username and password and the openid scope; tokens last 3600 seconds, and Zaptec says the password grant will be phased out for the code grant.

Limits

  • Peak rate limit of 10 requests per second per account; 429 responses need queues and backoff; pages hold at most 100 records
  • Installation current should change no more than once every 15 minutes, and only when AvailableCurrentMode is 0 (Default Charging Mode)
  • Service bus: two subscriptions per installation, a message TTL of 5 minutes, and removal after 14 days without traffic
  • Pause and resume commands need firmware above 3.2 on Pro and are rejected outside the documented ChargeOperationMode and FinalStopActive states

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 Zaptec API ↗

Questions and answers

How does Fibric learn that a charger's state changed?
From ChargerState messages on Zaptec's Azure Service Bus over AMQP 1.0. Each carries ChargerId, StateId, Timestamp, and ValueAsString. Zaptec documents this push path as the alternative to polling, which its usage guidelines rule out for charger and installation state.
Can Fibric start or stop a charge?
It can propose charger commands: RestartCharger, PauseStopCharging, ResumeCharging, and DeauthorizeStopCharging, sent through POST /api/chargers/{id}/sendCommand/{commandId} with owner or service access. Pause and resume need Pro firmware above 3.2. A person approves each command first.
Does this replace an OCPP management system?
No. Zaptec offers OCPP 1.6J at box level, where your CSMS controls the charger, and OCPP 1.6J Cloud, where Zaptec keeps load balancing and your system handles authentication. This connector reads the Zaptec API; pair it with the OCPP listing if your chargers report elsewhere.
Ask about Zaptec 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 Zaptec 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