Enphase API and SolarEdge API Integration for Solar Companies

How does the Enphase API work?

Enphase API v4 uses OAuth 2.0. Each request needs an access token and the API key of your application. Access tokens last one day and refresh tokens last one month, so a production integration needs automated refresh and a path to re-authorize when a refresh token expires. The base URL is https://api.enphaseenergy.com/api/v4/.

Enphase groups its endpoints into a Monitoring API (system details, production, consumption, battery and device data) and a Commissioning API (activations, user and company management). Plans start with a free Watt plan covering system details and site-level production and consumption, then paid Kilowatt and Megawatt tiers. The Partner Plan is for registered installers with 10 or more installations and opens all Monitoring and Commissioning endpoints.

How does the SolarEdge API work?

The SolarEdge Monitoring API uses an API key generated in the monitoring portal and returns JSON over HTTPS from monitoringapi.solaredge.com. Its documentation describes a limit of 300 requests per day, and the limit applies per account token and per site, so designs that poll every site every few minutes will be rate limited with HTTP 429 responses.

The practical approach is to use bulk and overview endpoints, cache aggressively, schedule pulls by site priority and back off on 429. Site-level and account-level keys behave differently, so decide early who owns the key: your company, or each customer.

What breaks in typical integrations?

Most failures are operational rather than conceptual.

• Refresh tokens expiring because a scheduled job failed for a month
• Customer revokes consent and the sync keeps retrying
• Rate limits exceeded after adding more sites
• Unit and time zone mismatches between Enphase and SolarEdge payloads
• Duplicate or missing intervals after a retry
• Schema changes from the vendor that silently return nulls

Where should the data go?

Typical destinations are a CRM that shows system status on the customer record, a service ticketing tool that opens a case when a site stops reporting, a billing system for PPA or lease invoices based on metered kWh, a customer app, or a data warehouse for fleet analytics.

For PPA billing the integration needs reconciled monthly energy per system and an audit trail, because the invoice amount depends directly on the reading. Vascoh stores raw vendor responses next to the normalized values so any invoice can be traced back to the source call.

Do you need an OAuth app, a partner agreement or just an API key?

It depends on whose data you read. Reading your own systems can use a single developer app. Reading customer systems at scale needs customer authorization through OAuth for Enphase and a managed set of API keys for SolarEdge. Check the current plan and terms with each vendor before design, since limits and access tiers are set by them and can change.

Testing deserves a plan of its own. Vendor sandboxes and real customer systems behave differently, so an integration should be run against a handful of real systems for at least a full billing cycle before it is trusted. Logging every call with status, duration and remaining quota gives an early warning when limits tighten. A small admin screen listing each connected system, its last successful sync and its authorization state turns most support questions into a single glance. Vascoh builds that screen as part of the work, because the integration is only as reliable as the speed at which someone notices a broken connection. Security deserves the same care: store tokens and API keys encrypted, restrict who can read them, and never log them in plain text.