SRP-Tarif-API

Exakte Tarife für Privathaushalte und detaillierte Stromrechnungen für Salt River Project (Metropolregion Phoenix, Arizona), berechnet aus den eingereichten Tarifbüchern von SRP und nicht geschätzt. Jede Antwort nennt das Dokument und die Seite, aus der sie stammt.

Live: https://utility-api-jn9g.onrender.com · Dokumentation: /docs

GET https://utility-api-jn9g.onrender.com/v1/tariff/rate?tariff_id=srp:E-26&at=2026-07-15T15:00:00

{
  "season": "summer_peak",
  "period": "on_peak",
  "rate_per_kwh": 0.2566,
  "components": [ ... ten unbundled line items ... ],
  "source": {
    "document_url": "https://www.srpnet.com/.../2025-Ratebook-with-Temporary-FPPAM.pdf",
    "page_refs": ["48-53"],
    "verified_by": "Courtney",
    "confidence": "verified"
  },
  "caveats": [ ... ]
}

Warum es das gibt

Die Tarife von SRP für Privathaushalte sind öffentlich, aber wirklich schwer zu berechnen. Die Preise ändern sich je nach Stunde, Wochentag, Saison und beobachtetem Feiertag, über ein Dutzend Tarifpläne hinweg, deren Definitionen nicht übereinstimmen:

• Saisons werden über den Abrechnungszeitraum definiert. Spitzenzeiten werden über das Kalenderdatum definiert. Bei E-26 bedeutet Sommer die Abrechnungszeiträume Mai, Juni, September und Oktober, aber das Spitzenlastfenster von 14–20 Uhr läuft vom 1. Mai bis 31. Oktober nach Kalenderdatum. Ein Abrechnungszeitraum, der den 31. Oktober überspannt, erhält die Preise einer Saison und zwei verschiedene Stundenklassifizierungen. Wenn man das zu einem einzigen „Saison“-Feld zusammenfasst, werden stillschweigend alle Übergangsmonate falsch abgerechnet.

• Tarife werden in Mountain Standard Time eingereicht, und Arizona stellt nicht auf Sommerzeit um. Jede generische Time-of-Use-Bibliothek, die auf Sommerzeit umstellt, liegt ein halbes Jahr lang um eine Stunde daneben.

• Tarife sind ungebündelte Komponentenstapel, keine einzelnen Zahlen. Der Brennstoff- und Strombezugskosten-Aufschlag sitzt im Stapel und bewegt sich nach eigenem Zeitplan, also muss er trennbar bleiben.

• Feiertage setzen einige Zeiträume außer Kraft, andere nicht. Bei E-26 ist die Spitzenzeit an Weihnachten ausgesetzt, während die Super-Nebenspitzenzeit weiterhin gilt.

Dieser Dienst modelliert all das aus den Einreichungen und zeigt seine Arbeit.

Related MCP server: ratebook-mcp

Abdeckung

Rufen Sie GET / oder GET /v1/tariff/plans auf, um die aktuelle Antwort zu erhalten. Stand der aktuellen Datenladung:

Nur Privathaushalte. Anfragen außerhalb eines abgedeckten Abrechnungszeitraums geben 422 zurück, zusammen mit den abgedeckten Zeiträumen.

Was es ablehnt und warum

Das ist der Teil, den man lesen sollte, bevor man sich darauf verlässt.

Nicht modellierte Tarifpläne. E-28 zahlt eine Gutschrift pro exportierter kWh, die das aktuelle Datenmodell nicht abbilden kann. Statt eine Rechnung zurückzugeben, die für jeden Kunden mit Dach-Solaranlage falsch wäre, lehnt der Dienst E-28 rundheraus ab und sagt das auch. Das zu beheben ist eine Schemaänderung, die unten verfolgt wird.

Nicht abgedeckte Zeiträume. Jede Datei deckt ein bestimmtes Abrechnungszeitraum-Fenster ab. Fragt man einen Zeitraum ab, für den keine Einreichung vorliegt, erhält man eine 422 mit der Auflistung dessen, was abgedeckt ist — niemals einen extrapolierten Tarif.

Nicht abbildbare Bestimmungen. Jeder Tarif trägt eine unmodeled_provisions-Liste, die in den Antworten als caveats auftaucht: die 300.000-Dollar-Obergrenze für die jährliche Energieeffizienz, das Ermessen von SRP, den Brennstoffaufschlag zwischen den Einreichungen anzupassen, und die Weitergabe von Steuern und Abgaben. Das sind reale Bedingungen, die sich ändern können, und sie werden ausgewiesen statt versteckt.

Steuern. Nicht enthalten. Staats-, Bezirks- und Gemeindesteuern hängen von der Lieferadresse ab.

MCP-Server

Derselbe Rechner ist auch als MCP-Server verfügbar, sodass Assistenten ihn direkt aufrufen können. Drei Werkzeuge: list_srp_plans, get_srp_rate, calculate_srp_bill. Kostenlos und lokal — keine Zahlung, kein Netzwerkaufruf.

{
  "mcpServers": {
    "srp-tariff": {
      "command": "C:\\path\\to\\utility-api\\.venv\\Scripts\\python.exe",
      "args": ["C:\\path\\to\\utility-api\\mcp_server.py"]
    }
  }
}

Windows-Hinweise, auf die harte Tour gelernt:

• Installieren Sie Abhängigkeiten explizit mit dem Interpreter der venv: & ".\.venv\Scripts\python.exe" -m pip install -r requirements.txt. Ein einfaches pip install könnte einen anderen Python verwenden, und der Server schlägt dann mit ModuleNotFoundError fehl.

• Wenn Claude Desktop aus dem Microsoft Store stammt, liest es eine sandboxed Konfigurationsdatei unter %LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\, nicht %APPDATA%\Claude\. Verwenden Sie Einstellungen → Entwickler → Konfiguration bearbeiten, um die Datei zu finden, die die App tatsächlich liest.

• Der Entwicklermodus muss aktiviert sein, damit lokale Server erscheinen.

Maschinenzahlungen (x402)

Die HTTP-Endpunkte sind außerdem pro Aufruf zahlbar über x402 — ein Agent empfängt eine 402, zahlt in USDC und versucht es erneut, ohne Konto oder API-Schlüssel. Derzeit auf Base Sepolia (Testnetz); das aktive Netzwerk wird unter GET / gemeldet.

/ und /v1/tariff/plans sind von Natur aus kostenlos: Ein Aufrufer muss in der Lage sein zu erfahren, was abgedeckt ist, bevor er entscheidet, wofür er zahlt.

Lokal ausführen

python -m venv .venv
.venv\Scripts\activate
python -m pip install -r requirements.txt
python -m pytest tests\ -v
python -m uvicorn server:app --reload

Die Zahlung wird nur aktiviert, wenn CDP_API_KEY_ID und X402_PAY_TO beide in .env gesetzt sind. Lassen Sie sie ungesetzt, um ohne Bezahlung zu laufen.

Datenmodell

Eine JSON-Datei pro Einreichung, nicht pro Tarifplan: data/tariffs/srp/<slug>@<from-billing-cycle>.json. Ein Tariffall oder eine vorübergehende Anpassung fügt eine Datei hinzu; sie bearbeitet niemals eine bestehende. Das Register schlüsselt nach tariff_id auf eine Liste von Versionen auf und wählt anhand des angefragten Abrechnungszeitraums aus, sodass historische Zeiträume beantwortbar bleiben.

Dateien werden gegen schemas/tariff-schema.v1.1.json validiert. Die Testsuite prüft, dass jeder Komponentenstapel in der Summe dem ausgewiesenen Gesamtbetrag entspricht, dass alle zwölf Monate genau einer Saison zugeordnet sind, dass jede Saison-/Zeitraum-Kombination, die der Kalender erzeugen kann, einen Preis hat, und dass eine Datei, die confidence: verified beansprucht, auch benennt, wer sie verifiziert hat und auf welchen Seiten.

Bekannte Lücken

• Ab November 2026 ist nichts modelliert. SRP veröffentlicht mehrere Tarifbuch-Varianten (Basis, temporär-FPPAM und TCA-Überarbeitungen), und welche für den November-Zyklus gilt, muss vor der Aufnahme gegen die Quelle bestätigt werden.

• Exportgutschriften (E-28, E-13, E-14, E-16) benötigen einen Gutschrift-Preistyp — Schema v1.2.

• Pro-rata-Abrechnung für teilweise Abrechnungszeiträume (Einzug, Auszug, Tarifwechsel) ist nicht abgebildet.

• Strukturierte Berechtigung. Ein Kunde mit Dach-Solaranlage von 2019 kann nicht auf E-26 sein, aber die Berechtigung ist derzeit Prosa, sodass nichts einen Aufrufer davon abhält, ihn damit zu bepreisen.

• Rundungskonvention ist pro Einzelposten, dann summiert. Ob SRP zuerst summiert und dann rundet, ist gegen eine echte Time-of-Use-Rechnung nicht verifiziert.

Genauigkeit und Haftungsausschluss

Tarife werden aus den eingereichten Tarifbüchern von SRP übertragen, und jede Datei hält fest, wer sie gegen welche Seiten verifiziert hat. Komponentenstapel werden maschinell darauf geprüft, dass sie in der Summe den ausgewiesenen Gesamtbeträgen entsprechen. Trotzdem ist dies eine inoffizielle Neuimplementierung: Sie ist weder mit SRP verbunden noch von SRP unterstützt, und sie sollte nicht die alleinige Grundlage für eine finanzielle Entscheidung sein. Verifizieren Sie anhand Ihrer eigenen Rechnung und der veröffentlichten Tarife von SRP.

Einreichungen ändern sich. Prüfen Sie retrieved_at in jeder Antwort und bestätigen Sie, dass der betreffende Zeitraum abgedeckt ist.

Erstellt von Killion Apps.