What the data for this category looks like
Energy storage-related revenue yield and daily market trend data originates from three primary sources: public APIs of domestic regional electricity spot trading markets, local SCADA monitoring systems of energy storage power stations, and grid dispatch grid-connected platforms. Data updates follow a T+1 end-of-day cycle. Full data calculation and release for the previous natural day are completed each early morning. Some real-time charge-discharge node data refreshes every 15 minutes. Daily reports only use end-of-day aggregated values. Data documents use standard JSON format, including fields such as unique power station identifier, rated installed power, total daily charge-discharge energy, daily grid settlement electricity price, allocated operation and maintenance costs, and daily revenue calculation value. Power units are kilowatts. Energy units are kilowatt-hours. Electricity price units are yuan per kilowatt-hour. Revenue calculation value units are yuan.
Constraints for HTTP interfaces and external systems
Multi-source data docking requires configuring multiple sets of authentication parameters and request addresses. Each must adapt to the distinct interface specifications of power trading platforms and station monitoring systems. The T+1 update cycle requires scheduled synchronization task trigger times to occur after the industry-standard 2 AM data release time. This avoids requesting data that has not yet been generated. The fixed JSON field structure requires interface requests to include a power station ID list as a query parameter. Return fields must strictly match preset key names, otherwise data parsing will fail. Revenue calculation values are denominated in yuan and involve financial reconciliation. External system docking must retain sufficient numerical precision, otherwise reconciliation deviations will occur. Some grid platform public APIs impose QPS rate limits. Reasonable request frequency configuration is required to avoid interface call failures due to rate limiting.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
external_api_timeout | 30 seconds | Energy storage data source interfaces are mostly internal enterprise or grid platform APIs, with typical response delays of 10-25 seconds. Setting 30 seconds covers normal requests and avoids long-term blocking |
api_auth_type | API_KEY authentication | Most energy storage trading and monitoring platforms require fixed API keys for identity verification, which aligns with industry standard docking specifications |
request_rate_limit | 10 requests per minute | Grid dispatch platform public APIs typically limit single API key requests to no more than 15 times per minute. Setting 10 requests avoids triggering rate limits |
data_sync_cron | 0 3 1 * * ? | Triggers T+1 data synchronization at 3 AM daily, matching the energy storage daily report update cycle |
response_field_mapping | station ID: station_id, daily profit: daily_profit | Matches the standard field names in energy storage data documents, preventing data parsing failures due to field mismatches |
precision_keep_digits | 2 | Energy storage revenue calculation values are denominated in yuan. Retaining two decimal places meets the precision requirements for financial reconciliation |
The parameter values provided on this page are common recommended starting points for configuration. Actual values are affected by material form, data volume, and business rules. Specific issues require case-by-case analysis. It is recommended to test on your own samples before finalizing settings.
Three Common Misconfigurations
- A 401 Unauthorized status code is returned when calling energy storage data interfaces. This occurs when
api_auth_typeis not correctly configured as API_KEY authentication, or the passed key does not match the platform's requirements. - Scheduled synchronization tasks return empty data after execution. This happens when
data_sync_cronis set earlier than the energy storage platform's daily report update time, resulting in requests being made before data is generated. - Local deployment instances on version V4.9.3 experience connection timeouts when calling external interfaces in an Ubuntu Server 24.04 environment. This is caused by not opening outbound ports for the corresponding interfaces in system firewall rules, preventing requests from reaching external data sources.
How to Verify Successful Configuration
- Manually call the configured HTTP interface. Check that the returned JSON fields include preset key names such as
station_idanddaily_profit, and that numerical formats match unit requirements. - Review scheduled task logs. Confirm that daily early morning synchronization tasks run after the energy storage platform's update time, and that no error records are present.
- Import test data returned by the interface into the external system's test environment. Verify that the precision of revenue calculation values meets expected requirements.
- Adjust the
request_rate_limitvalue to be below the rate limit threshold. After triggering a rate limit, check that FastGPT's rate limit logs are generated normally.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.