Any fleet charging optimization system is only as good as the tariff data it operates against. You can build a sophisticated demand dispatch engine, implement per-vehicle feasibility horizon tracking, and deploy OCPP 2.0 smart charging profiles across a depot — and still schedule charging against the wrong peak window if your tariff data is stale or structurally incomplete.
The practical reality of obtaining live utility tariff data in the United States is more complicated than it sounds. There is no uniform national tariff data API. Utilities vary enormously in data accessibility, from structured machine-readable feeds to nothing more than PDFs posted to a tariff page updated occasionally. What a fleet charging platform can actually automate depends entirely on which utilities serve the depots in question.
This article covers the data landscape as it actually exists — the mechanisms available, the limitations that matter operationally, and the fallback strategies that keep scheduling systems accurate when utility data isn't machine-readable.
The Green Button Standard and Its Limits
The closest thing to a standard API for utility electricity data in the US is the Green Button initiative, developed under the Department of Energy and now administered through the North American Energy Standards Board. Green Button defines two data access mechanisms: Green Button Download My Data (static file export) and Green Button Connect My Data (API-based data sharing).
Green Button Connect My Data is the version relevant to automated tariff ingestion. It defines OAuth-based authorization allowing third-party applications to access a customer's interval usage data on an ongoing basis. The data format is ESPI (Energy Services Provider Interface), an XML schema that encodes meter readings, intervals, and some billing-related metadata.
The limitation for fleet charging optimization is significant: Green Button Connect My Data is primarily designed to return historical interval usage data — what a meter actually recorded, at 15-minute intervals, for past billing periods. It is not designed to return forward-looking tariff schedules, rate calendars, or pricing forecasts. Using Green Button to get your consumption data is valuable for billing reconciliation and demand analysis, but it doesn't give you the tariff calendar you need to decide when to charge tomorrow night.
Some utilities have extended their Green Button implementations with additional endpoints that return rate plan information — PG&E in California has done this with varying degrees of completeness. Pacific Northwest utilities are more limited. PGE (Portland General Electric) offers Green Button Download for residential customers and limited commercial access; its API capabilities for commercial rate schedule data are not publicly documented as machine-readable endpoints as of this writing. Pacific Power's Green Button availability is similarly constrained for commercial accounts.
OATI and Wholesale Market Data
Utilities in the Western Interconnection typically participate in the Western Energy Imbalance Market (EIM), operated by CAISO, or have bilateral arrangements that involve OATI (Open Access Technology International) for scheduling and dispatch. Real-time locational marginal prices (LMPs) and day-ahead market prices are available through CAISO's OASIS API for EIM participants.
For fleet charging optimization, wholesale market prices are a proxy — not a substitute — for retail tariff schedules. A commercial fleet customer pays retail rates, which are derived from wholesale costs plus utility overhead, and are defined by the tariff schedule on their account, not by real-time LMPs. That said, wholesale price signals do predict retail rate period transitions with reasonable reliability in systems where TOU periods are designed to reflect wholesale market dynamics, which is true for most WECC utilities.
CAISO OASIS provides day-ahead and real-time market prices through public REST endpoints, updated on defined intervals. For Oregon utilities that participate in the EIM, these prices can serve as a real-time grid stress indicator to supplement tariff calendar scheduling — useful for informing demand response decisions but not a replacement for confirmed tariff data in the optimization engine.
Utility-Specific Tariff APIs
A growing number of utilities, particularly larger IOUs (Investor-Owned Utilities), publish structured tariff data through developer portals. The utility API landscape as it exists for Pacific Northwest fleet operators:
Portland General Electric
PGE has published developer documentation for certain data access programs, primarily oriented around demand response and smart grid programs. For commercial customers enrolled in their Electric Avenue or similar EV-specific programs, there may be structured rate data available through program enrollment APIs. However, for general commercial tariff schedule retrieval — fetching the Schedule 32 rate calendar programmatically — PGE does not publish a documented public API endpoint. Rate schedule data is available in PDF format from PGE's tariff schedules page and can be parsed from the Oregon PUC tariff database.
Pacific Power
Pacific Power (a PacifiCorp subsidiary) has more limited developer-facing infrastructure than larger utilities. Commercial rate schedule information is available through the Oregon PUC and Washington UTC tariff databases in structured formats, but not through a Pacific Power-published API. Updates to rate schedules follow the PUC filing process, which provides advance notice of changes but requires monitoring the docket system rather than an automated push notification.
Clark Public Utilities
As a PUD (Public Utility District), Clark Public Utilities in Washington operates outside the IOU regulatory structure and has its own rate-setting process. Rate information is available through their published tariff documents, which are updated through their board resolution process. No public API access is available for automated rate schedule retrieval.
Open Tariff Databases as a Fallback
For utilities without machine-readable APIs, the most reliable approach is to build against structured data from open tariff aggregation databases. OpenEI (the Open Energy Information platform, maintained by NREL) maintains a utility rate database — the URDB (Utility Rate Database) — that includes rate schedule definitions for hundreds of US utilities, including the rate period structures, energy charges by period, and demand charge parameters.
The URDB provides a REST API with endpoints for querying rate schedules by utility name, zip code, or rate ID. Response data includes structured JSON representations of rate period definitions, including weekday/weekend differentiation, seasonal windows, and tiered charge structures. The data quality varies by utility and by how recently rates were updated in the database.
The operational limitation of URDB is update latency. Rate changes filed with state PUCs are not always reflected in URDB promptly. For fleet operators on consequential commercial rate schedules, URDB data should be validated against the current filed tariff before being used as the primary optimization input, and discrepancies should be resolved against the PUC filing as ground truth.
Building a Tariff Data Pipeline
A practical tariff data pipeline for a multi-utility fleet charging platform combines these sources with appropriate reliability and fallback logic:
- Primary source: Utility-provided structured API where available (Green Button Connect My Data for usage data; utility developer portal for rate data where published)
- Secondary source: URDB API for rate schedule structure, cross-validated against filed tariff on a monthly basis
- Fallback: Manually maintained rate schedule objects, updated by operations staff from PUC filings, with versioning and effective date tracking
- Alerting: Automated checks that flag when tariff data hasn't been validated within 30 days, or when the utility's filed tariff version differs from the version in the local rate database
The alerting layer deserves emphasis. We're not saying manual rate maintenance is an acceptable long-term solution — it isn't, and the operational burden grows with fleet size and utility diversity. But the failure mode of automated tariff ingestion without validation is that stale data produces incorrect scheduling decisions silently. An alert when tariff data hasn't been refreshed is preferable to discovering the discrepancy in the monthly utility bill.
Real-Time Price Signals vs. Day-Ahead Schedules
One architectural question in tariff-based scheduling is whether to optimize against day-ahead price forecasts or against the confirmed tariff calendar for the current billing period. For fleets on fixed TOU rate schedules — where the peak and off-peak windows are defined in the tariff document and don't change day-to-day — the tariff calendar is the right optimization input. Day-ahead market prices from CAISO OASIS add noise without necessarily improving scheduling decisions.
The exception is utilities that offer real-time pricing (RTP) or critical peak pricing (CPP) programs, where the energy charge for a given period can vary based on grid conditions. Under CPP, for example, a utility may dispatch a critical peak event with limited advance notice (sometimes 24 hours, sometimes day-of), during which energy prices spike substantially above normal peak rates. Fleet charging systems that receive CPP event notifications in real time can defer charging away from those periods if the fleet's feasibility horizon allows.
PGE has offered CPP programs to large commercial customers in Oregon. For enrolled fleet operators, integrating CPP event notifications into the dispatch logic is high-value: the price differential during a CPP event can be significant enough to justify deferring charging even into a window that's normally less preferred from a demand management perspective. The integration requirement is access to PGE's CPP notification feed, which is available through program enrollment rather than a public API.
The broader principle is that tariff data integration should be treated as a living system, not a one-time setup. Utilities change rates, add programs, and occasionally deprecate APIs. A fleet charging platform that treats tariff data as infrastructure — with monitoring, versioning, and fallback handling — will consistently outperform one that treats tariff data as a configuration parameter.