The electricity chart looks reassuring. Consumption appears to have fallen after a customer moved premises. In reality, the application stopped receiving one meter's readings and quietly treated the empty intervals as zero. The graph is technically rendered correctly; the business conclusion is wrong.
For Danish property operators, energy advisers and software companies building an ElOverblik integration, this is a more useful starting point than another forecasting demo. Before software can recommend when to run equipment or compare buildings, it must explain which meters it can see, what each interval represents and whether access still exists.
The Danish integration has more than one permission state
ElOverblik's API guide distinguishes direct customer access from third-party access on behalf of customers. It also explains digital-key expiry and withdrawal. The official ThirdParty API documentation states that access is limited to active customer authorizations and describes the separate data-access token. These are concrete integration requirements, not merely onboarding details.
Our design recommendation is to keep three records separate: the application's provider credentials, each customer's authorization and the metering points available through that authorization. A healthy provider credential does not prove that a particular customer still shares a meter. Conversely, one withdrawn authorization should not make the entire platform appear unavailable.
This distinction matters commercially. An energy-service customer wants a clear next step when a building disappears from a report. Asking them to reconnect everything because the system cannot identify the affected permission creates avoidable support work.
Draw the missing-data state before the normal chart
A time series should carry both values and completeness information. A received zero is a measurement. An absent interval is an absence. A failed import is an operational event. Combining all three as a blank or zero makes the interface simpler at the cost of reliability.
Show the latest successful refresh and the covered period. If a monthly comparison excludes an unavailable meter, make that exclusion visible beside the total. The user should not need to open a developer console to discover that the comparison covers a different portfolio from last month.
Decide how a partial day behaves in exports and notifications as well. A dashboard can display an incomplete badge while a scheduled email presents the same total without qualification. The data contract should carry the completeness state into every output, including spreadsheets and any AI-generated explanation.
A building and a metering point are not the same object
An operator may organize work by property, tenant or cost centre. The energy source organizes data around its own metering identifiers. Create an explicit mapping, with effective dates, between these structures. Do not use a customer-entered address as the only key.
Consider an illustrative portfolio with a building that gains a second metering point. If the application treats the new point as a replacement, historical comparisons lose part of the story. If it adds the point to every past period, the old totals change incorrectly. The mapping must explain when each point contributes and why.
Tenant changes need similar care. Separate the property's operational history from the customer's permission to access particular data. Define retention and visibility with the organization's responsible owners. Possessing an old downloaded file does not automatically justify making it visible to a new tenant or adviser.
Withdrawal needs a product journey
When an authorization disappears, stop requesting data under that authorization and update dependent jobs. The application should tell the operator what was observed without pretending to know why the customer made the change. A neutral message such as access no longer available is more accurate than payment overdue or customer disconnected.
Existing recommendations need review too. A weekly comparison built from a previously complete portfolio may become unsuitable for current decisions. Mark affected outputs and pause recommendations that rely on unavailable coverage. Do not allow a confident summary generator to fill the gap with an estimated explanation unless estimation is an explicitly approved and clearly labelled feature.
If access returns, reconcile the newly available period before resuming routine outputs. A reconnect action should not create a second customer record or duplicate previously imported measurements. Track import identity and the period being refreshed so that recovery remains understandable.
Put operational ownership in the proposal
A credible development proposal names who renews credentials, monitors failed imports and responds to changed authorizations. It also describes which failures customers can resolve themselves. These responsibilities belong in the service design, because they will persist after the initial engineering team hands over the application.
Separate the cost of the connector from portfolio mapping, data-quality screens and recommendations. The first working API response is only one component. If existing property records are inconsistent, budget for a controlled mapping exercise rather than assuming that an address-matching algorithm can approve every relationship.
Ask for an export that preserves metering identifiers, interval coverage and mapping history. That makes future migration and independent checks possible. A product that exports only the polished chart leaves the buyer dependent on the application's interpretation of its own data.
A pilot that exposes the real work
Choose a small authorized portfolio with a known change history. Include a withdrawn authorization, an expired credential, a missing interval and a reassigned metering point in the test fixtures. The acceptance demonstration should show both the customer-facing explanation and the operator's recovery path.
Measure how quickly the team can identify an incomplete report, how much manual reconciliation remains and whether a repeated import changes previously validated totals unexpectedly. Establish those baselines in your own workflow. Avoid promising an energy saving before the product has even demonstrated that its inputs cover the same assets consistently.
Our guide to an API integration statement of work helps define ownership and exception handling. The software maintenance agreement guide covers the responsibilities that continue after launch. TuniCyberLabs can build the connector and operational application through our custom software development service. Show us your meter portfolio and current reporting process to scope a first release that explains the data before advising anyone to act on it.