On this page
- Why is registry connectivity the bottleneck in REC operations?
- How does a climate advisory firm use a REC registry API instead of building its own?
- How does an ETRM platform add registry operations for its customers?
- How does a retail energy supplier run compliance retirements and trades in one place?
- Which registry operations model fits your team?
- How does Innovo support every model on one platform?
Every company that touches renewable energy certificates ends up rebuilding the same plumbing. Advisory firms build registry integrations, software vendors build them again for their customers, and suppliers log into one registry portal at a time to file compliance retirements. The certificates are the same. The work around them gets rebuilt over and over.
Quick Answer: Energy companies automate REC registry operations by connecting their registry accounts to one system that standardizes data and actions across registries such as M-RETS, PJM-GATS, WREGIS, NEPOOL GIS and NYGATS. Teams then sync inventory, transfer and retire certificates, and track trades either through a REC registry API inside their own software or through a shared web platform. They don't need a separate integration or login for each registry.
See how Solas connects to every registry your portfolio touches → Solutions
Why is registry connectivity the bottleneck in REC operations?
Registry connectivity is the bottleneck because every REC registry works differently, and nothing in the market standardizes them. Each tracking system has its own login method, data model, supported actions and processing times. Any team holding certificates in more than one registry ends up maintaining a separate process for each.
The differences are concrete. Some registries offer an API, and others only offer a web login. Some support subaccounts, and others don't. Some let you accept an incoming transfer, and others move certificates without an inbox step. Here's what a team has to handle for each registry it uses:
| What varies by registry | Why it creates work |
|---|---|
| How you sign in (API key, username and password, two-factor codes) | Every credential type needs its own setup, storage and renewal |
| Data fields and naming (eligibility, tier, vintage formats) | Positions can't be compared until someone normalizes them |
| Supported actions (transfer, accept, retire, subaccounts) | Workflows that work in one registry fail in another |
| Processing time and status updates | Teams check portals by hand to confirm an action went through |
Most compliance markets add to the load. State renewable portfolio standards in places like Pennsylvania, New Jersey and Washington, D.C. each set their own tiers and carve-outs, and a supplier serving several states has to retire certificates against every one of them. For more on how inventory sprawls across registries, see how to manage REC inventory across multiple registries.
The REC market doesn't have a certificate problem. It has a plumbing problem, and every firm is paying to rebuild the same pipes.
How does a climate advisory firm use a REC registry API instead of building its own?
A climate advisory firm uses a REC registry API to replace one-off registry integrations with a single standardized connection that its own tools call. The firm's engineers stop building and maintaining a separate integration for every registry. Instead, they spend their time on the systems that make the business distinctive.
The client profile. Climate advisory and environmental-commodities firms source and manage certificates on behalf of corporate clients, often across U.S. and international registries. Many run their own internal systems, such as an energy trading and risk management (ETRM) platform, and have engineers on staff. For these firms, receipts, deliveries, transfers and retirements are often manual, and building a direct connection to each registry is slow, ongoing work.
What they do with Innovo. These firms work through the Solas API rather than the web interface. Their internal receipts and deliveries tools call Solas for each of these workflows:
- Inventory: certificate positions across every connected registry and subaccount, in one standardized format
- Tagging: labels for sorting, reporting and allocating certificates to client programs
- Transfers: sending certificates between registry accounts through standard API calls
- Retirements: retiring certificates and capturing the confirmation records that compliance and client claims depend on
- Data cross-checks: comparing registry data against what the firm's own systems expect, to catch discrepancies early
When a registry changes its API or website, Innovo updates the connection behind the gateway, so the firm's systems keep working without a code change.
What changes. Engineers build against one interface instead of one per registry. Registry maintenance becomes a service the firm receives, backed by around-the-clock support, rather than a backlog it owns.
How does an ETRM platform add registry operations for its customers?
An ETRM platform adds registry operations by connecting its software to the Solas REC registry API, so its customers can see and act on certificates without leaving the trading system. The platform gets registry connectivity for its whole customer base without building integrations to each registry itself.
The client profile. ETRM and trading software vendors serve power producers, renewable developers and energy traders who book REC deals in their systems. The vendors typically don't hold registry accounts themselves; they act on behalf of their customers. Registry connectivity is the missing step between a trade booked in the ETRM and a certificate actually moving in a registry.
What they do with Innovo. As a channel partner, the ETRM pulls registry data through the Solas API into its own position management and reporting. A few features matter specifically to a software partner:
- Separate connections per desk or entity. A customer can connect the same registry more than once, for example with different API keys or subaccounts for different trading desks or legal entities, and keep each one separate.
- Sandbox and production environments. Partners build and demo against registry sandbox accounts, then switch to production with real certificates.
- Role-based access. Admin, Member and View Only roles control who can initiate transfers and retirements.
- Customer privacy. Each customer's workspace is separate, and Innovo staff don't have visibility into a customer's positions or inventory.
What it looks like at scale. One partner customer, a renewable developer, has 239 registry accounts across 7 registries connected through Solas: ERCOT, M-RETS, NAR, NC-RETS, NEPOOL GIS, NYGATS and PJM-GATS. Those accounts sync continuously. Without a shared connection layer, every one of them would be a login to maintain by hand.
An ETRM knows what you traded. A registry knows what you own. The integration between them is where most reconciliation errors live.
How does a retail energy supplier run compliance retirements and trades in one place?
A retail energy supplier runs compliance retirements and trades in one place by using the Solas web platform for both its registry operations and its REC transactions. Retirements, transfers, trade entry, contracts, invoices and certificate delivery all live on the same record, and Innovo manages settlement.
The client profile. Retail energy suppliers sell power to homes and businesses in several states, and each state sets its own renewable portfolio standard with its own tiers and carve-outs. That means buying and retiring large volumes of certificates against multiple compliance programs every year. Without a shared system, retirements mean logging into a registry portal and working through certificates one batch at a time, while trades and invoices live somewhere else.
What they do with Innovo. Suppliers work in the Solas interface rather than the API:
- Compliance retirements. The team selects eligible certificates by tier and vintage, retires them against the right utility territory and subaccount, and queues the next batch while earlier ones process. Once the first retirements clear, larger batches follow.
- Transfers. Certificates move between the supplier's accounts and its counterparties' accounts from the same screen.
- Trades. The team enters trade details and attaches contracts directly on the trade.
- Invoicing and delivery. Invoices are issued from the trade, and REC delivery is tracked against it, from awaiting delivery through delivered.
- Settlement. Innovo manages settlement, so payment and REC delivery are tracked and completed on the same trade record.
What changes. Compliance season stops being a portal marathon. The team handles trading and retirements in one workspace, and every action leaves a record in Task History for auditors and regulators.
Which registry operations model fits your team?
The right model depends on who owns your systems. Teams with their own software and engineers usually connect through the API. Software vendors embed the API for their customers. Operations teams without a dedicated engineering function run everything in the platform.
| Direct API | Partner integration | Platform | |
|---|---|---|---|
| Best for | Advisory firms, trading houses and buyers with in-house systems | ETRMs and other software vendors serving many customers | Retail suppliers, utilities and brokers running operations day to day |
| Who builds the interface | You, on top of the Solas API | The partner, inside its own product | Innovo |
| Registry maintenance | Innovo | Innovo | Innovo |
| Typical workflows | Inventory sync, transfers, retirements and data checks feeding internal tools | Registry data inside position management and reporting | Retirements, transfers, trade entry, contracts, invoicing and delivery |
| Where the data lives | Your systems, via API | The partner's product, via API | Solas, with exports and API access |
The three models aren't exclusive. The same organization can use the platform for compliance work and the API for reporting. For the operations detail behind each module, read how Solas replaces a patchwork of registry logins.
This flexibility only works if the layer underneath is the same for everyone.
How does Innovo support every model on one platform?
Solas is Innovo's REC operations platform, and every model in this post runs on the same backbone. Registry Gateway connects to M-RETS, PJM-GATS, WREGIS, NEPOOL GIS, NYGATS, ERCOT, NAR, MIRECS, NC-RETS and Evident (I-REC) using your existing registry credentials. Inventory normalizes certificates across those registries. Operations handles transfers and retirements, with approval policies and a full Task History. Trades, invoices and bills keep commercial activity and certificate delivery on one record, with Innovo managing settlement.
Everything you see in the platform is also available through the API, with keys and documentation in the developer section and separate sandbox and production environments. Innovo is SOC 2 Type II certified and never takes custody of customer funds. One backbone, and you choose the interface.
Registry operations used to be something every firm built for itself. The firms in this post decided it was infrastructure, and spent their effort on the work only they can do.
Related reading
- How to manage REC inventory across multiple registries: why holdings drift when they live in several registries, and how to keep one source of truth.
- How Solas replaces a patchwork of registry logins: a module-by-module look at Registry Gateway, Inventory, Transfers, Retirements and Task History.
- Solutions: how Innovo supports REC registry operations and settlement.
Frequently Asked Questions
What is a REC registry API?
A REC registry API is a programming interface that lets software read certificate positions and run actions such as transfers and retirements in a renewable energy certificate registry. The Solas API standardizes those actions across multiple registries, so developers write one integration instead of one per registry.
Do I need new registry accounts to use Solas?
No. Solas connects to your existing registry accounts with the credentials you already use. Your accounts, subaccounts and facility records stay as they are in the registry. For M-RETS, Innovo can also create a platform-managed account if you don't have one.
Can Innovo see my REC inventory?
No. Each customer's workspace is separate, and Innovo staff don't have visibility into your positions or inventory. Access inside your organization is controlled by roles (Admin, Member and View Only).
How is Solas different from the registry's own website or API?
A registry's own portal or API covers only that registry, with its own data format and login. Solas connects to multiple registries at once, normalizes the data into one model and logs every action in one place. Your team doesn't have to learn each registry's quirks.
Can an ETRM or other trading system connect to Solas?
Yes. ETRMs and other trading systems connect through the Solas API to pull inventory, transfer and retirement data into their own position management and reporting. Partners can build and test against sandbox registry accounts before going live.