A daily carbon report needs a clearly identified series, a price unit and an honest description of time. An API response arriving now does not establish that its price was assessed now.
The OilPriceAPI EU carbon reporting workflow uses EU_CARBON_EUR, an aggregated daily record in EUR per tonne of CO2. It provides a downloadable Python example and CSV output for recurring reports. This series should not be presented as an official exchange settlement, auction result or compliance valuation.
Choose data for the task
Before selecting a source, write down the instrument, observation type, reporting period and licensing requirements your report needs. A latest aggregated record cannot substitute for a historical series or a specified contract settlement. If a process requires an official market value, use the designated source and confirm the relevant instrument and date.
| Task | Required evidence |
|---|---|
| Daily reference report | Series identity, price, unit, record time and source limitations |
| Historical analysis | Documented historical coverage and observation methodology |
| Contract or settlement reporting | The instrument and official value required by that process |
| Budget scenario | Explicit assumptions, modeled quantities and a labeled reference price |
sbb-itb-a92d0a3
Keep record time separate from market time
The carbon workflow identifies its time basis as record_time_only. Preserve that limitation in the exported report. Do not relabel the record timestamp as a market assessment, trade or settlement timestamp.
A report should show when it was generated separately from the time attached to the price record. If the source does not provide the market-time detail your process requires, mark that detail unavailable. Refreshing a report more often does not make the underlying assessment more frequent.
Use the reporting example
- Open the EU carbon workflow and review its coverage and limitations.
- Download the reporting example and follow the page’s setup instructions, keeping the API key in an environment variable.
- Run the carbon report with an account entitled to the required series.
- Inspect the exported CSV before connecting it to a spreadsheet or recurring process.
- Retain the source record and report-generation time alongside the result.
The example checks the record before producing a usable report. Treat an unavailable preview or failed request as unavailable data; do not insert a plausible price to keep a report looking complete.
Validate the failure paths
- Confirm the returned series, EUR currency and price unit.
- Reject missing, nonnumeric or nonpositive prices.
- Reject future timestamps and flag records outside the reporting freshness policy.
- Resolve authentication or dataset-access errors before repeating requests.
- Respect rate limits and use bounded retries for temporary failures.
Keep the last successful result visibly dated when showing it during an outage. Never label it current merely because the dashboard loaded successfully.
Use reference prices without overstating the result
For an internal scenario, a modeled quantity multiplied by a reference price can illustrate price sensitivity. Label the quantity, price date and assumptions. That calculation alone does not determine an accounting entry, allowance requirement or final compliance cost.
The daily workflow does not establish intraday trading suitability, historical backfill access or automatic price-webhook availability. Confirm any additional capability against the documentation and your account before building around it.
Build the daily EU carbon report, then check access for your required datasets.