Commercial solar in Cyprus: brief an API access migration

Treat an API migration as a new access question

A commercial solar business replacing an older data connection should ask what the new integration actually needs. A login that worked for one developer portal is not proof that another API version will accept it. The migration proposal should identify the version, the authorised systems and the owner's approval process before promising a working connection.

The Enphase v4 API FAQ describes its v4 developer portal as independent of the older portal, with separate application credentials. It says developers need authorisation from the system owner. It also describes different account plans. These statements support a specific access enquiry, rather than an assumption that existing credentials or subscriptions automatically migrate.

This guide helps a buyer commission an integration service. It does not provide authentication code, recommend a particular plan or authorise anyone to retrieve another party's records. The appointed developer should use current manufacturer documentation and the supported consent process for the actual accounts and systems.

Describe the existing service without exposing secrets

Ask the current provider for a plain-language inventory of the connection it maintains. Record the platform version, the systems covered, the service purpose and the business contact responsible for it. Keep credentials, tokens and recovery material out of the inventory circulated for quotation comparison.

Identify the receiving service too. A report arriving in an inbox, a dashboard maintained by a contractor and a business system importing records can all depend on a connection without sharing the same owner or support arrangement. The migration provider needs the actual scope, not merely a screenshot showing a familiar logo.

If the business does not know which version it uses, mark that as an investigation task. Do not label it v2 because it is old, or label it v4 because a supplier's current brochure mentions v4. Ask the responsible provider to establish the fact and explain its evidence.

Work through a fictional two-site proposal

The following references are invented. They illustrate a buyer's authorisation and coverage record, not API configuration steps.

Approval from S1's owner does not establish approval for S2. Nor does identifying C1's version prove that M1's connection works. The provider must show what systems the new authorised service actually covers. A buyer should keep these as separate acceptance questions.

If S2 remains unauthorised, the provider can propose an S1-only stage or another clearly bounded arrangement. The owner should not receive a completion statement implying both sites are covered. A partly completed migration can be described accurately without hiding the missing approval.

Separate portal registration from system permission

Ask the provider to explain the roles of the developer account, the application and the system owner's authorisation in its proposed service. The FAQ's separation of portals makes it especially important to identify which account and application the proposal concerns. Existing access elsewhere does not answer every new permission question.

The procurement team does not need the actual secret values to compare offers. It needs to know who controls the relevant accounts, who maintains the application and how supported access will be granted and later reviewed. The developer can arrange implementation through an appropriate secure process.

If a quotation asks the business to email all account passwords to several suppliers, ask for the supported access method instead. A service proposal should make the authorised roles understandable without turning the comparison pack into a collection of credentials.

Make plan and operating costs visible

Request the platform plan assumed by the proposal and the basis for that choice. Ask the provider to confirm current availability and terms for the actual service. The existence of several documented plans does not establish which one supports a particular business's intended usage.

Separate the platform charge, if any, from the developer's setup and ongoing service fees. Ask who receives the platform invoice, who pays it and what happens when requirements change. Request applicable VAT treatment and a process for approving additional work or charges.

Do not copy an old plan name or price into a permanent migration budget without checking it. The provider should state the assumptions underlying its current offer. The buyer can then compare costs against the same intended sites and deliverables.

Test the new service before calling the migration complete

Agree a small acceptance demonstration appropriate to the commissioned work. For fictional S1, the provider might supply the named report or agreed record set through the new supported connection, with its source and period identified. The buyer should ask its receiving team whether it can use the output.

If the old and new service produce differently labelled records, ask the provider to explain the mapping and limitations. A successful login is not the same deliverable as a usable report. Conversely, an old saved report does not prove that the new connection is operating.

Solarpanels is a starting point for a commercial-solar data-service enquiry using M1's scope and the two site references. Comparison is relevant when comparing integration-service proposals. Confirm the actual provider, its accepted work and the manufacturer's current requirements. These links do not grant access or promise that either site is eligible for a particular platform plan.

Record what remains in service afterwards

At handover, request the current supported connection inventory, responsible contacts and the accepted coverage record. Ask the provider how the old connection will be handled under the agreed migration plan. The buyer should retain control of decisions about access and service termination through authorised processes.

The fictional case closes separately for S1 and S2. M1 is complete for both only when its agreed deliverables and permissions are evidenced for both. A clear version-and-access brief makes a migration reviewable without assuming an older account, a new application and an owner's consent are interchangeable.