Exports and distribution

Getting data out of Softee, in the format the recipient expects

Energy reporting always ends up leaving the tool: into a spreadsheet for the board, into a file for a third party, into an information system for consolidation. Here are the outbound paths that genuinely exist — and, just as precisely, those that do not.

For energy managers and systems teams who have to feed internal reporting, a third party or a data warehouse, without re-keying.

Request a demonstration

How do you get data out into a spreadsheet?

Through a spreadsheet export you configure on four axes, from the management workspace. This is the export you trigger yourself, and the one that covers most one-off requests.

The sources

indicators, site parameters, sensor types.

The interval

last twelve months, last day, current year, month or week, or free dates.

The aggregation

day, month, quarter, half-year, year.

The grouping

site categories, meters, sensor types, energies, indicators.

Can a recurring export be scheduled?

Yes: a daily, weekly or monthly export, produced in CSV, Excel or JSON, and delivered by one of four paths — download, drop on an FTP server, email with a subject and recipients in To, Cc and Bcc, or publication to a message queue, either a queue or an exchange with a routing key.

A scheduled export is set up with you: its configuration is handled by the Softee team rather than from the interface.

A format a third party expects. One export mode produces a file in the fixed format expected by a third-party ESG platform, from a selection of sensor types.

The capability is real and verifiable in the code; we do not name the platform, for want of an agreement allowing us to. The singular is accurate: there is only one format of this kind.

Is there an API to retrieve the data?

Yes. The product exposes a REST API whose OpenAPI specification is published by the application, readable under ReDoc and Swagger UI. This is not a theoretical argument: the application’s own client is generated from that specification, so the specification is current by construction rather than by good intentions.

Two clarifications that will save you a misunderstanding: access remains authenticated, and there is no public developer portal. This is not an open API — it is the product’s API, documented.

What other outbound paths exist?

Three, narrow ones: the export of a sensor’s data, the export of the contract completeness check, and the alert email notification to the defined recipients, triggered by the daily evaluation.

And on-screen reporting, which is not an export but remains a distribution path: the dashboards you compose, readable by the users your administrator has authorised — three workspaces separate consultation, management and administration, with a permissions matrix per role.

What does not exist, and what we will not imply

  • No PDF report export, and no formatted report sent automatically.
  • No Power BI or live spreadsheet connector. Data leaves as a file, over a message queue or through the API — there is no data source to plug in.
  • No outbound webhook beyond the message queue used by scheduled exports.
  • No regulatory report generation. The product produces no document intended for a public authority, and it files nothing on OPERAT.
  • No third-party platform named. The export in a third-party ESG platform’s format exists; we describe it generically, for want of an agreement to name it.

Frequently asked questions about exports and reporting

A spreadsheet export on demand, and scheduled exports in CSV, Excel or JSON. Scheduled exports are delivered by download, FTP drop, email with a subject and recipients in To, Cc and Bcc, or publication to a message queue. The product’s REST API returns JSON.
Yes: a daily, weekly or monthly export, in CSV, Excel or JSON, delivered by download, FTP, email or message queue. A scheduled export is set up with you by the Softee team rather than from the interface.
Yes. The product exposes a REST API whose OpenAPI specification is published by the application, readable under ReDoc and Swagger UI; the application’s client is generated from that specification, which keeps it current by construction. Access remains authenticated and there is no public developer portal: this is not an open API, it is the product’s API, documented.
No. There is no PDF report export, no formatted report sent automatically, no Power BI or live spreadsheet connector, and no regulatory report generation. The available outputs are the spreadsheet, CSV or JSON file, the message queue, the alert email and the REST API.
Not through a dedicated connector: none exists, neither for Power BI nor for a live spreadsheet. The two real paths are the authenticated REST API, documented by its OpenAPI specification, and the scheduled export dropped on an FTP server or published to a message queue, in CSV or JSON. That is enough to feed a data warehouse, provided you plan for the integration work on your side.
No. No code in the shipped product exchanges with an ADEME system, and the product does not generate a file in the OPERAT import format. Exports come out as a spreadsheet, CSV or JSON, according to a configuration you choose; entry on the platform remains yours. Nor do we announce it as a forthcoming change.

Tell us who consumes your data

A board dashboard, a third party with an imposed format, an internal data warehouse. We will tell you which of these paths it goes through — or that there is none, which is a useful answer sooner rather than later.

Request a demonstration