Miks kohandatud integratsioonide loomine Energy Attribute Certificate (EAC) registritega on lõks

Corporate engineering teams usually end up assessing the web of Energy Attribute Certificate (EAC) registries in the market and quickly realise they have a decision to make.

• A) Do we try to build these integrations ourselves?
• B) Do we let our team continue to waste hours hopping between platforms?
• C) Do we look for an existing integration?

In full honesty: we're here as a software provider to dissuade you from A and B. You'll have to believe us when we tell you that's not just because we have a business interest in doing so, but it's because cleaner visibility across markets, fundamentally, is a hard task that took Soldera years to solve - we were founded in 2024 and have been working on our Registry Bridge infrastructure ever since.

When many of the registries you wish to integrate with are lacking APIs altogether, it is really bespoke connective tissue - custom builds for execution in every market. Your engineering talent will never face the same task twice: spreading their effort across country-specific portals as they attempt to reconcile the various login pathways, account rules, transfer protocols, differing cancellation evidence packs, and disclosure deadlines that exist between markets.

Why are EAC registry integrations so complex? Do some have normal APIs?

You'd assume they all would have APIs, but no. Registries were built by different software teams as controlled administrative systems for government agencies, not as developer-friendly products (or user-friendly products, for that matter). Take Europe's GO system for instance: the mesh of AIB-connected EECS GO registries , at its core, revolves around an interoperable settlement-system, the "AIB Hub" - but on the surface, the registries themselves are not made equal.

For example, if you were the competent authority within a national government (stay with us here), and wanted to start your own registry, you'd likely look to see who built existing registries to ensure your product could be up to the AIB-Hub standard. You'd be met with a list of 9 different service providers (at the time of writing), spanning 30+ registries, each of whom has built a platform that is intended for a controlled and connected transfer experience between one another - but each service provider has not considered the fact that users access multiple registries. They want to log in to registries in different markets to control their entire portfolio. Yet only some provide APIs. Here's a non-exhaustive, high-level overview of the scale of the problem in major markets

• Germany's HNKR Registry has no public API: https://www.hknr.de/Uba
• Spain's CNMC Registry has no public API: https://gdo.cnmc.es/
• Netherlands ' CertiQ has no public API: https://verticer.eu/en/
• Three of Belgium's registries have no public APIs
• Poland's TGE RGP registry has no public API: https://rgp.tge.pl/
• Sweden's CESAR registry has a very functionally limited API: https://cesar.energimyndigheten.se/sv/
• Finland's Finextra platform has a functionally limited API: https://go.finextra.fi/app/login

And that's just for a handful of European registries (not including the countless "niche" markets across the continent) serving participants of the Guarantee of Origin market. Also worth remembering: The UK's OFGEM RER System for REGO management and Evident's I-REC system both have unique rules, logins and layouts, baked into their various operational processes, requiring different document formats.

The overall moral of the story is that if your team assumes (as we once did, years ago) that there is one stable REST interface waiting underneath each and every market, the truly nasty work arrives later. We use "nasty" here primarily because it's a multidimensional problem: the struggle arrives not just from a technical integration standpoint, but from making sure your integration adheres in a compliant format to the local-market knowledge. For developers, market knowledge has very little to do with core technical ability.

Where custom integrations usually cause problems:

• Ongoing cost of maintenance: Portal layouts all-too-frequently change without any warning or versioned developer notes.
• Time-wasting integration hurdles: Manual authentication and 2FA quirks cause seriously inconsistent blocks that require creative and expensive workarounds such as systems with permanent uptime and running costs
• Learning by doing: Only when processing transactions at scale can some true registry quirks get ironed out. Believe us, we've faced the reality of cruel, irrational errors at the registry level that appear only when evidence is urgently needed. At times, we've had to flag these bugs to a registry operator ourselves, and they got fixed.
• Downstream consequences: Consequences that emerge when there are gaps in your audit-ready evidence - and these gaps appear when you make an error in your integration process.

What should corporate teams build themselves?

We observe that our clients do one thing better than anything else: their core business. So why waste time that could be spent focusing on sustainability strategy? In the context of building: be pragmatic. Build the internal, company-focused systems on top of EAC connectors that actually already work , rather than burning years of product capacity maintaining a private museum of registry frontends. Thankfully, EAC connectors that already work do exist.

What's the solution?

Soldera's Registry Bridge is done-for-you, a settlement layer and API for EACs that acts as frictionless end-to-end compliance. It exists to solve exactly this: we've deployed existing accounts in every market to provide a seamless hosted account and API surface for buying, receiving, holding, sending, selling, cancelling, and exporting evidence across 30+ registries, including even the most challenging markets without public APIs. Use registry bridge directly from the Soldera Web App, or, if your existing company software setup requires programmatic/integrated registry actions, your team can use Soldera's API as the pre-built connector underneath. It enables all registry behaviours: including auto-routed cancellations via local registries where available.

This is also mission critical: local, registry-backed cancellation certificates are the clear best practice for credible RE100 renewable electricity claims, and this is often overlooked - despite the fact that local cancellations will almost certainly face more audit scrutiny as geographical matching becomes more relevant for sustainability teams (see our article on the rules of the GHG-P tightening towards geographic matching). So instead of rebuilding the registry maze yourself, trust those who have walked that troublesome road before you so you don't have to.