PV inverter cloud APIs, ranked by integration difficulty: 9 production notes

Evaluation Dimensions

We score each inverter cloud API across six dimensions:

Dimension	What it means
Public API	Whether the API is openly accessible vs. requires a private commercial negotiation
Auth method	OAuth2 / API Key / signed request — complexity varies widely
Data resolution	5 min / 15 min / 1 hour / summary-only — affects freshness and usability
Historical backfill	Whether older data can be retrieved, and how far back
Downlink control	Remote on/off, power capping, parameter writes
Doc quality	Directly determines first-time onboarding effort

Top vendors at a glance

The notes below come from three years of production integration in Zenergy Monitor, cross-checked against the actual interface docs vendors handed us. Each section cites the document version we worked from. Engineering reference only — not commercial advice.

Huawei FusionSolar / iMaster NetEco

Document: iMaster NetEco V600R023C00 Northbound Interface Reference V6 (SmartPVMS)

• Public API: ✅ RESTful northbound interface, HTTPS-only, JSON payloads
• Auth: Username/password login returns an XSRF-TOKEN in the response header; pass it on every subsequent request. Token expires after 30 minutes of inactivity. Login rate-limited to 5 calls per 10 minutes per northbound user; 5 wrong passwords locks the account for 30 minutes. Max 5 northbound users per system.
• Resolution: Plant real-time + hourly / daily / monthly / yearly; device real-time + 5-min + history + daily / monthly / yearly
• Backfill: Device-level history endpoint (getDevHistoryKpi) queries any time window at 5-min granularity
• Downlink: DRM (power capping), forced charge/discharge, on/off-grid switching, shutdown-with-cap (status codes 513 for grid-with-cap, 772 for shutdown-with-cap, etc.)
• Pain points: Active lifecycle management — the doc carries simultaneous "added / revised / pending sunset" sections. getStationList is already flagged for sunset in SPC210; integrations need to switch to /thirdData/stations. Throttling policy changed between legacy and new accounts created after June 2022.
• ZenovaConnect note: We keep an SPC-version probe layer; field mappings branch by version. DRM downlink is only exposed to customers with O&M sign-off.

Sungrow iSolarCloud

Document: vendor OpenAPI doc (delivered offline, no public PDF link)

• Public API: ✅ Third-party app must be enabled in the cloud console first
• Auth: App Key + App Secret, per-request signed
• Resolution: 5-minute
• Backfill: Generally back to device commissioning; some endpoints page by month
• Downlink: Specific models only (inverter + storage PCS)
• Pain points: Some energy fields are reported in kWh × 10, must be divided back in the adapter. Timestamps are device-local — to aggregate to UTC you need plant longitude/latitude first.
• ZenovaConnect note: Sungrow is a top-3 share in our production fleet; field normalization is the heaviest lift among all vendors we cover.

GoodWe SEMS

Document: GoodWe domestic OpenAPI v1.0.1.2 (2022-03-16)

• Public API: ✅ Endpoint openapi.sems.com.cn, HTTP POST + JSON
• Auth: account / pwd login returns a token, valid for 2 hours, passed in header. Three rate-limit tiers: per-minute / per-hour / per-day.
• Resolution: Real-time + daily power curve + day/month/year energy; no public 5-minute endpoint
• Backfill: Composed via daily power curve + day/month/year energy. Batch endpoints (sections 2.3.6 ~ 2.3.8) only landed in 1.0.1.2.
• Downlink: ❌ Not documented
• Pain points: Strict tenant isolation — "inverters GoodWe shipped to distributor A are invisible to distributor B". Cross-tier access requires opening a ticket. HT models extended fields to vpv5~vpv12 / istr17~istr24; older clients silently miss them. Alarm code table (3.3) is a separate dictionary you have to maintain.
• ZenovaConnect note: Authorize the upstream tier-1 organization before integration or you'll loop on 401. We diff our alarm dictionary against the vendor's on every doc revision.

Solis (Ginlong)

Document: Ginlong Cloud API V2.0

• Public API: ✅ Endpoint api.ginlong.com:13333, API ID + Secret obtained from ginlongcloud.com console
• Auth: AWS-S3-style signed request — Authorization: API <apiId>:<sign>, where sign = base64(HmacSHA1(secret, POST\n + Content-MD5\n + Content-Type\n + Date\n + CanonicalizedResource)). Content-MD5 (base64 of MD5 of body) is mandatory.
• Resolution: All endpoints fixed at 5-minute update cadence
• Backfill: Four tiers — "day real-time" / "monthly daily" / "yearly monthly" / "yearly" — each windowed and paginated
• Downlink: Not listed in V2.0
• Pain points: Date header must be within ±15 min of server time — NTP drift in production causes silent 401s. Rate limit 2 req/sec; batch endpoint caps at 60,000 inverters per 5-min window. EPM and weather-station devices are on separate endpoint sets.
• ZenovaConnect note: We isolated signing into a small SDK after burning a day on Content-MD5 line-ending differences. For Date drift, just reuse the server's Date response header to estimate offset.

Sofar (via Solarman)

Document: SolarMAN OpenAPI v1.1.7

• Public API: ✅ Via the Solarman open platform api.solarmanpv.com; Sofar's dataloggers are predominantly Solarman gateways
• Auth: OAuth 2.0 — APP_ID + APP_SECRET → access_token (2-month validity) + refresh_token. Pass Authorization: <access_token> header.
• Resolution: Device real-time + device history; plant real-time + plant history
• Backfill: Device / plant history endpoints query by time window
• Downlink: ✅ Section 3.7 (device control) + 3.9 (custom Modbus-register write). v1.1.7 added caller-side timeout config.
• Pain points: Dual rate-limit regime — 300 req/10s on general endpoints, 50 req/min on control endpoints. Passwords must be SHA256-hashed before sending. Test and production APP_IDs are not interchangeable. Resetting the password or changing user role invalidates the current token immediately.
• ZenovaConnect note: Solarman is an "aggregator gateway" supplier — integrating Solarman covers many brands at once, but data fidelity is bound by Solarman's gateway sampling rate, not the inverter's.

APsystems

Document: APsystems OpenAPI User Manual V1.6 (2024-02-07, English)

• Public API: ✅ App Id + App Secret issued by email approval
• Auth: HMAC signature since V1.2. Five headers per request: X-CA-AppId / X-CA-Timestamp / X-CA-Nonce / X-CA-Signature-Method (HmacSHA256 or HmacSHA1) / X-CA-Signature. String-to-sign order: Timestamp / Nonce / AppId / RequestPath / HTTPMethod / SignatureMethod.
• Resolution: No 5-minute endpoint — energy_level of hourly | daily | monthly | yearly only
• Backfill: Compose via date_range + energy_level; hourly returns 24 points per natural day, daily returns N points per natural month, etc.
• Downlink: ❌ Read-only
• Pain points: Accounts are closed if unused for 6 months (documented). Inverter-level data only landed in V1.5 (Nov 2023) — older clients only see ECU-level. Pricing varies by call volume and data range.
• ZenovaConnect note: APsystems data model is two-level (ECU → individual inverter), we flatten it. Hourly-only resolution affects alarm precision; we recommend pairing with site-side edge collection for customers who need <1-hour SLAs.

Sigenergy

Document: Sigenergy Northbound API draft v2.3 (2025-03-04, Chinese)

• Public API: ✅ Doc delivered (55 pages)
• Auth: Body text is rendered as embedded images (screenshot-style layout), so automated text extraction returns only chapter headers — key parameters per the integration team's working copy
• Resolution: Same as above — doc is readable, field-by-field details per vendor sample
• Backfill: Per vendor reference
• Downlink: Table of contents shows control / task-dispatch / alarm sections (chapters 8–12) — control endpoints exist
• Pain points: Still labelled "draft v2.3" so the surface is evolving. Sigenergy's flagship products are storage + integrated ESS, so expect a PCS / battery-cluster–oriented data model rather than a pure PV one.
• ZenovaConnect note: For storage-led vendors we maintain extra battery-cluster / SOH / charge-discharge-policy fields by default rather than only mirroring the inverter side.

Zhongxin (中鑫)

Document: Zhongxin Digital Platform OpenAPI – PV V2.0

• Public API: ✅ HTTP POST + JSON, paths shaped as /api/v{ver}/{service}/{method}
• Auth: HMAC-SHA256 signature, six fixed headers: accessKeyId / signatureMethod / signatureVersion / requestId (UUID) / timestamp (ms) / signature. String-to-sign sorts all params ASCII, URL-encodes them, then POST&%2F&<encoded querystring>, HMAC-SHA256 with the secret, base64.
• Resolution: Driven by individual measurement points — call listPointByDeviceId, then queryDevicePointDataByPointCode. Granularity matches whatever the point is configured to log.
• Backfill: Historical point endpoint (section 2.8) accepts a time window
• Downlink: Not listed in the doc
• Pain points: Asset model spans PV + storage + distribution + EV charging + integrated energy (appendix lists 11 collection groups: grid-tie meters, transformers, EV connectors, battery cluster, etc.). The adapter has to fan-out by deviceType to different field mappers.
• ZenovaConnect note: Point-driven schemas are friendly to adapt to, but confirm with the upstream which points are actually wired up — otherwise you get a lot of legitimate-looking nulls.

Kehua (科华 Energy Cloud)

Document: Kehua Energy Cloud HTTP Interface Protocol V1.02 (last revised 2024-06)

• Public API: ✅ Endpoint energy.kehua.com, REST + JSON, response code is the string "0" / "1"
• Auth: northboundLogin (username/password) returns data.authorization token, passed in header
• Resolution: Plant real-time + device real-time. Device payload is a three-way split: ycInfos (telemetry) / alarmInfos (alarms) / yxStatus (status signals)
• Backfill: A single-day single-inverter history endpoint was only added 2024-06; before that, only current + day-cumulative were available
• Downlink: ✅ getDeviceSettingInfo returns a control-point list (SetDataObject) with statusFlag / rangeData / accuracy / isSigned to validate writes — schema is designed to drive UI directly
• Pain points: Doc ships as Excel (.xlsx), not PDF, with 6 major revisions between 2019 and 2024. Field units are embedded inside the display name (e.g. "active power set (kW)") — you have to parse them out.
• ZenovaConnect note: Kehua's control-point schema (SetDataObject + StatusDescriptionObject) is unusually "data-driven UI"-friendly — we generate downlink forms straight from it.

One-line summary

Public APIs are now the default for top vendors. The real difference lives in historical backfill, alarm semantics, downlink control, and ongoing doc churn.

Across the nine vendors, auth methods cluster into three camps:

• Signed request (Solis, APsystems, Zhongxin, Sungrow): HMAC computed per request; Date / Timestamp drift must be carefully managed
• OAuth 2.0 (Sofar / Solarman): dual-token + refresh, with multiple invalidation triggers
• Login token (Huawei, GoodWe, Kehua): username + password exchanged for a short-lived token — simpler but weaker on multi-tenant isolation

On resolution: only Huawei, Solis, Sungrow, and (close behind) Kehua truly serve 5-minute data. APsystems tops out at hourly, GoodWe at daily power curve + day-cumulative, Zhongxin depends on point configuration.

On downlink: Huawei is the most complete (DRM + forced charge/discharge + power-cap), Solarman/Sofar and Kehua next, the rest are essentially read-only.

ZenovaConnect tracks and normalizes these vendor-by-vendor — your team shouldn't have to absorb the details every time a new SPC drops or a doc revision moves an endpoint.

How we use this ranking

ZenovaConnect's protocol matrix displays each vendor by maturity: Production-verified / Beta / In-progress / Queued. New vendor requests are prioritized by use case and commercial weight. Self-Hosted customers get the adapter source we've already shipped — including the signing, throttle handling, and field-normalization logic for each of the vendors above.