Best Practices
Optimize your Grid Status API usage for performance, reliability, and cost-effectiveness.
Query Optimization
Always Use Time Filters
Unbounded queries can be slow and expensive. Always specify start_time and end_time when querying time-series data.
# Queries entire dataset - slow and expensive
curl -H "Accept-Encoding: br, gzip" "https://api.gridstatus.io/v1/datasets/ercot_lmp_by_settlement_point/query?api_key=YOUR_API_KEY"# Bounded time range with location filter - fast and efficient
curl -H "Accept-Encoding: br, gzip" "https://api.gridstatus.io/v1/datasets/ercot_lmp_by_settlement_point/query?\
start_time=2026-01-01&\
end_time=2026-01-02&\
filter_column=location&\
filter_value=HB_HOUSTON&\
api_key=YOUR_API_KEY"Filter by Subseries
Most LMP and load datasets contain data for many locations. Filter to the specific locations you need.
Why this matters: LMP datasets like pjm_lmp_real_time_5_min contain 10,000+ pricing nodes. Querying all nodes for a single day can return millions of rows. If you only need hub prices for trading decisions, filter to those specific hubs.
# Returns data for all 10,000+ nodes
curl -H "Accept-Encoding: br, gzip" "https://api.gridstatus.io/v1/datasets/pjm_lmp_real_time_5_min/query?api_key=YOUR_API_KEY"# Returns data for one specific hub
curl -H "Accept-Encoding: br, gzip" "https://api.gridstatus.io/v1/datasets/pjm_lmp_real_time_5_min/query?\
start_time=2026-01-01&\
end_time=2026-01-02&\
filter_column=location&\
filter_value=WESTERN%20HUB&\
api_key=YOUR_API_KEY"Select Only Needed Columns
Reduce response size by requesting only the columns you need.
# Only get timestamp, location, and LMP
curl -H "Accept-Encoding: br, gzip" "https://api.gridstatus.io/v1/datasets/caiso_lmp_real_time_5_min/query?\
start_time=2026-01-01&\
end_time=2026-01-02&\
columns=interval_start_utc,location,lmp&\
filter_column=location&\
filter_value=TH_SP15_GEN-APND&\
api_key=YOUR_API_KEY"# Only get timestamp, location, and LMP - skip energy, congestion, loss components
df = client.get_dataset(
"caiso_lmp_real_time_5_min",
start="2026-01-01",
end="2026-01-02",
columns=["interval_start_utc", "location", "lmp"],
filter_column="location",
filter_value="TH_SP15_GEN-APND"
)
# Response is ~60% smaller than without column selectionRequest Compressed Responses
The API compresses responses with brotli or gzip whenever your client advertises support through the Accept-Encoding request header. For large dataset queries this shrinks the transfer by up to ~20x — a 60 MB JSON response drops to roughly 3 MB — which means faster downloads, lower bandwidth costs, and fewer timeouts.
Most HTTP clients request compression automatically, including the Grid Status Python client, requests, httpx, and web browsers. Set the header explicitly if your integration — for example, some ETL platforms or no-code HTTP connectors — does not send it by default.
# Send Accept-Encoding to receive a compressed response (brotli preferred, gzip fallback).
# curl --compressed sets this header and decompresses the response for you automatically.
curl -H "Accept-Encoding: br, gzip" "https://api.gridstatus.io/v1/datasets/ercot_lmp_by_settlement_point/query?\
start_time=2026-01-01&\
end_time=2026-01-02&\
filter_column=location&\
filter_value=HB_HOUSTON&\
limit=100&\
api_key=YOUR_API_KEY"# The Grid Status Python client requests compression automatically - no action needed.
# requests and httpx also send Accept-Encoding and decompress responses by default.
df = client.get_dataset(
"ercot_lmp_by_settlement_point",
start="2026-01-01",
end="2026-01-02",
filter_column="location",
filter_value="HB_HOUSTON",
limit=100,
)Pagination Strategies
Use Cursor Pagination for Large Datasets
Cursor-based pagination is more efficient than offset-based for large result sets. The client handles this automatically. For more see Pagination documentation.
# The client handles pagination automatically - no manual cursor management needed
df = client.get_dataset(
"ercot_fuel_mix",
start="2026-01-01",
end="2026-01-02"
)
# All pages are fetched and combined into a single DataFrame
print(f"Retrieved {len(df)} total rows")Batch Large Date Ranges
For queries spanning months or years, batch into smaller chunks.
Error Handling
Implement Retry Logic
Handle transient errors gracefully with exponential backoff.
Monitor API Usage
Check usage before large operations to avoid hitting limits.
Data Quality
Data quality checks are critical for energy trading and operational applications where decisions are time-sensitive.
Verify Data Freshness
Check that data is current before using it in production.
Use case: Before executing trades based on current prices, verify the data is within an acceptable age threshold. Stale data could lead to trading on outdated price signals.
Validate Query Results
Verify that returned data meets expectations.
Performance Summary
Use time filters
High
Always set start_time and end_time
Filter by location
High
Use filter_column/filter_value
Resampling
High
Remove resampling. Fetch raw data first and resample locally.
Batch large requests
High
Split into smaller chunks
Retry on errors
High
Implement exponential backoff (included in the client)
Compress responses
High
Send Accept-Encoding: br, gzip (automatic in most clients)
Select columns
Medium
Use columns parameter
Cursor pagination
Medium
Use cursor instead of page
Monitor usage
Medium
Check quota before large queries
Related Documentation
Advanced Query Features - Filtering, resampling, timezone
Error Handling - Handle errors gracefully
Utility Endpoints - API usage, metadata, column values
Last updated
Was this helpful?

