Overview¶

RECreation (previously known as DigitalCER in legacy documentation) is a REST API platform for managing Renewable Energy Communities (RECs) under Portuguese regulation (Decreto-Lei 15/2022).

In these communities, a handful of operations can occur that you will set off via this API. To do so you will first need to configure the community structure and provide the platform with energy measurement data from the DSO or forecast data (if doing simulations or executing pre-delivery processes).

What is a REC?¶

A Renewable Energy Community is a legal entity formed by members — prosumers, consumers, and/or producers — who collectively share locally produced renewable energy. Locally generated energy (typically solar PV) is allocated among members, reducing grid dependence and lowering collective energy costs. These communities are registered with a DSO and receive monthly (sometimes daily) measurement data of consumption and generation.

Key Actors¶

graph TD
    SU[SUPER_USER] -->|creates & manages all| C[Communities]
    A[ADMIN] -->|creates & manages community| MEMBERS[Members, Meters, Resources]
    MB[MEMBER] -->|views own data + aggregated| D[Dashboard]

Role	Scope	Description
`SUPER_USER`	Platform	Manages every aspect of the platform. If you are integrating machine-to-machine scenarios or communicating through the API, you will likely have a `SUPER_USER` account.
`ADMIN`	Community	Role of community manager that has access to whole communities. Useful for interfacing with the platform through our frontend Web UI.
`MEMBER`	Own data	Access to the member dashboard (requires verified email). Can only see their own data and community-aggregated information. If using the API, members can be just generic representations of users from your own system and do not require emails or proper accounts.

Operation Modes¶

Mode	Description
Real Operation	A real licensed REC that receives data from the DSO (via API or SFTP depending on your needs). There are checks in place to guarantee correct data handling and thus bigger restrictions on what can be done.
Simulation	Testing and planning mode — RECreation emulates DSO allocation from provided generation/consumption profiles. You will likely not use this in API integrations, although it could be necessary for certain functionalities like sizing (scaling up optimization) simulations and rerunning historical data for comparison.

Note

Most of our initial testing used Simulation mode because DSO specifications are still evolving and DSO data may not yet be available for all deployments. Please be patient as we work in real operation with your integrations.

Platform Architecture¶

graph TD
    FE[Frontend Dashboard] --> API[RECreation REST API]
    API --> DB[(Database)]
    API --> SIZ[Sizing Module]
    API --> EMS[Energy Management Systems]
    API --> TRX[Transaction Module]
    EMS -->|generate setpoints| Resources
    TRX -->|market clearing| SETTLE[Settlement Module]
    SETTLE -->|billing outputs| EXPORT[Export through API, Excel or PDF]

Pre-delivery and Post-delivery¶

We have a concept of two stages regarding the platform. If you are working with Forecasts and most EMS, you are likely operating in the Pre-delivery phase. This likely means you are trying to optimize what your assets will do in the future.

If you have received DSO data, you are likely in the Post-delivery phase. This means you will create transactions and allocate the energy based on what the DSO sent you. If you are operating with Dynamic Coefficients, you will first generate coefficients a.k.a Bilateral Energy Allocations and send these to the DSO for validation. Otherwise, you run the market, then the settlement and you may use the results to help you bill your members.

In real life, you could work with both side by side. For example, first you generate forecasts based on historical data for tomorroww, then you feed different EMS modules (with different optimization strategies) your battery data and you receive Setpoints of battery behavior for tomorrow. You will apply this behavior and when the DSO sends you data in the future, their measurements will reflect the optimal behavior you predicted.

Top Level Glossary¶

Here's a few terms for platform and functionality you may want to look up in these docs as you move along.

Term	Description
Communities	The top-level REC entity. Contains all members, meters, resources, and configuration.
Members	Participants in a community — Anchor/Host, Promoter, or Consumer/OffTaker/NonHost. Or simply just a basic "Member". Each member owns one or more resources.
Meters	Measurement points in the community hierarchy: CPEs (DSO-registered meters), Internal meters (behind a CPE), and Aggregator CPEs (entire community measurements aggregated by the DSO and with a specific contract). Define the structure tree used for energy allocation.
Contracts	Retailer contract parameters attached to a CPE meter — buy/sell tariff structures, voltage level, and tariff cycle. Buy and Sell tariffs are optional but voltage level, tariff cycles and contracted power are not.
Resources	Energy assets attached to meters: consumption units (IC/IU), production units (SCPU/IPR), storage, EVs, and heat pumps. The atomic unit for ownership and trading in the local energy market.
Sessions	One 15-minute ISP (Interval Settlement Period). It's our model for a 15 minute interval that joins meters, resources, members and their data, as well as the results of operations and their status (are they finalized, pending action etc...).
Market	The local energy market (LEM) clearing algorithm that runs within a session, matching producers and consumers and generating transactions at a price and energy.
Settlement	Financial computation of revenues and costs for each member after market clearing. Produces billing data per ISP.
Loads	User made meter measurements(consumption/generation), uploaded per 15-minute interval. Can be used for CPEs in Simulation mode. Otherwise, only for INTERNAL meters.
DSO Loads	Measurement data received from the Distribution System Operator for each CPE — consumption, injection, surplus allocation, and imputed energy — in 15-minute intervals.
Forecast	Predicted generation and consumption profiles used in pre-delivery phases for energy management optimization and simulation scenarios.
Opportunity Costs	Per-CPE, per-interval cost values representing the buy and sell price of each CPE with their retailer.
Bilateral Prices	Agreed energy prices between a specific provider–receiver member pair, either per interval (dynamic) or static. Used with `BILATERAL_PRICE` or `TREE_DNAC` market rates and their `FIXED` counterparts.
Bilateral Energy Allocations	Dynamic allocation coefficients computed per provider–receiver CPE pair per 15-minute interval. Submitted to the DSO for validation before final settlement in `DYNAMIC` allocation communities.
Fixed Coefficients	Static energy allocation coefficients submitted to the DSO for communities using the `FIXED` allocation method.
RESP	Rede Elétrica de Serviço Público — the Portuguese public electricity grid. CPE pairs connected only through RESP are subject to self-consumption grid-access tariffs on traded energy. By default, most CPEs are.
ERSE Files	Regulatory data files published by ERSE (Entidade Reguladora dos Serviços Energéticos) — network access tariffs, loss factors and tariff cycles. Mandatory to compute opportunity costs and thus calculate potential savings.
OMIE	The Iberian electricity market operator. Provides day-ahead spot prices used as a pricing reference in indexed contracts.
Energy Management	Pre-delivery optimization and flexibility modules (OSTEC, GDBN) that generate setpoints for controllable assets such as batteries, EVs, and heat pumps.
Sizing	Pre-delivery module for large-scale simulations to evaluate optimal asset sizing (e.g. PV capacity, battery size) for a community before deployment.
Simulator	Community operation mode that emulates DSO energy allocation from internal meter data, enabling testing and historical re-runs without real DSO data feeds.
Billing Guides	PDF/Excel financial summary reports generated per date range, showing each member's revenues, costs, and energy data. Settlement outputs can be retrieved by API.