India Electricity Tariff & Bill Verification API
Verified Indian electricity billing & regulatory intelligence API. State-wise tariff calculations, evidence traceability, ToD/FPPAS/FAC, solar/net-metering, bill-impact analytics and fail-closed regulatory updates.
PEI turns Indian electricity regulation into executable, source-traceable billing infrastructure.
One central place for the PEI API
This portal combines release information, integration guidance, client onboarding, security requirements, legal terms and privacy disclosures. Technical endpoint details remain in the versioned API documentation and OpenAPI specification.
/v1/. This portal is synced to
API V1.2.0 and Controller
V2.2.8, but it does not execute or
modify tariff calculations.
Coverage and release status
Bihar release ID: BR-2026-27-VERIFIED-STRICT-BASE-V1
· Runtime gates: 29/29
· Controller: V2.2.8
MSEDCL Complete Payable V2 is production-active for approved profiles. TPC-D, AEML and BEST remain routed through the Maharashtra statewide verified base-tariff architecture. Verified base-tariff calculations are available through the public API for the released statewide scope. FAC/FPPPA, payable ToD and other bill components remain explicit, fail-closed or non-payable unless the applicable verified source and billing context are available.
Gujarat Electricity Tariff API 2026-27 →
FY 2026-27 coverage is live through
POST /v1/calculate for
DGVCL, MGVCL, PGVCL and UGVCL. Current scope covers
DOMESTIC_URBAN and DOMESTIC_RURAL
postpaid residential consumers with verified energy slabs and
connected-load fixed charges. FPPAS, ToU, subsidy, electricity duty/taxes,
prepaid and unresolved BPL/category semantics remain excluded or fail-closed.
FY 2026-27 Rajasthan coverage is live through
POST /v1/calculate across
41 verified districts with explicit routing for
JVVNL, AVVNL and JDVVNL.
Release ID:
RJ-2026-27-VERIFIED-SHADOW-V1.
District/licensee mismatches fail closed and automatic licensee fallback
is disabled. FPPAS and electricity duty remain verified shadow components;
subsidy and regulatory-charge eligibility remain fail-closed where context
is incomplete. Production payable remains disabled.
Solar/net-metering is planned for Rajasthan V1.1+.
Released calculations and verification workflows use verified regulatory data and deterministic arithmetic. The API does not claim to reproduce an exact current utility bill. Bihar monetary subsidy, current FPPAS/FPPPA/FPPCA, Maharashtra FAC/FPPPA, Telangana current-period FCA/FPPAS, payable ToD where not explicitly released, statutory levies, taxes, duties, meter rent, arrears, rebates and other bill components remain excluded or fail-closed unless a response explicitly states otherwise.
Built for energy products, not tariff-table scraping
API Pricing
Start with a controlled pilot and move to production as your traffic, state coverage and support requirements grow.
Quick start
Production requests use HTTPS and a dedicated API key supplied through a supported header. Query-string API keys are rejected.
Header authentication
Health request
Capability discovery
Tariff calculation & bill verification
billing_days is optional and backward compatible. Executable
values are currently 25, 30 and 40 only. For supported Bihar domestic
calculations, POST /calculate may evaluate the frozen entitlement
contract and apply the verified monetary subsidy core. An approved exact-month
FPPAS version may also affect the verified monetary composition when its
recovery-month and billing conditions match. The response preserves the
base-tariff result separately and exposes final_payable,
electricity-duty and ancillary-charge status. Resolve exact category codes
and required fields through GET /categories before calculation.
Routes and least-privilege scopes
| Route | Method | Scope | Purpose |
|---|---|---|---|
/health |
GET | health:read |
Service, version and release status |
/capabilities |
GET | health:read |
State-aware enabled and blocked calculation features |
/states |
GET | states:read |
Released states |
/categories |
GET | categories:read |
Verified categories and required inputs across supported states; licensee-specific states require explicit routing context |
/tariffs |
GET | tariffs:read |
Verified tariff rows across supported state and licensee scopes |
/subsidy-entitlement |
GET | tariffs:read |
State-specific entitlement contract where available; monetary application is handled separately by POST /calculate |
/fppas-periods |
GET | tariffs:read |
Verified FPPAS period evidence; only an approved exact-month version may be applied by POST /calculate |
/sources |
GET | sources:read |
Public source traceability |
/calculate |
POST | calculate:write |
Tariff calculation and bill-verification workflows across supported multi-state scopes, with state and licensee-specific routing, evidence traceability and fail-closed handling for unresolved regulatory components. Verified Shadow and Verified Tariff Estimation capabilities are exposed explicitly by state, including Jharkhand VERIFIED_TARIFF_ESTIMATION_V1. |
/solar-savings |
POST | calculate:write |
Verified solar before/after tariff comparison where supported |
/category-resolver |
POST | calculate:write |
Resolve caller-declared tariff context to a verified category where supported |
Recommended integration flow
/health and validate API and release identity.
/capabilities before enabling bill components.
/states and /categories.
/tariffs, /sources and the verified evidence/contract routes.
/calculate; consume final_payable and honour all unresolved-component disclosures.
MCP Server V1
Connect AI agents and MCP-compatible clients directly to the tariff, bill-verification and regulatory-intelligence API without duplicating state-specific electricity logic.
- Endpoint:
https://powerexpertindia.com/api/mcp/index.php - Transport: Streamable HTTP
- Authentication:
X-API-Key: YOUR_API_KEYorAuthorization: Bearer YOUR_API_KEY - Tools:
health,capabilities,states,categories,tariffs,sources,calculate,solar_savings
MCP agent contract
| Step | Purpose |
|---|---|
initialize | Establish the MCP session and negotiate the client/server connection. |
tools/list | Discover available PEI tools and their input schemas. |
tools/call | Invoke a PEI tool such as capabilities, states, tariffs, sources or calculate. |
capabilities | Read state-specific production, Verified Shadow and payable-hold status before monetary execution. |
Agents must not infer production-payable status from state availability alone. Use
states and capabilities first and honour
production_payable, verification status and unresolved-component disclosures.
Authentication failures return 401, insufficient scopes/state access return 403,
and invalid request contracts fail explicitly rather than falling back to another state or tariff.
Credential and security requirements
- Store the key in a server-side secret manager or protected environment variable.
- Do not expose a production key in browser JavaScript, mobile bundles or public repositories.
- Never put a key in a URL, screenshot or support message.
- Use the smallest required route scopes and approved state access.
- Configure exact browser origins where CORS access is required.
- Request immediate rotation after suspected exposure.
Rate limits and retries
The default production profile is 60 requests per minute per key with a 20-request burst allowance within 10 seconds. Limits are registry-driven and may differ by client plan.
- Respect
429and theRetry-Afterheader. - Use bounded exponential backoff and request deduplication.
- Do not retry validation or authentication errors without correcting the request.
- Use caching for stable catalogue responses where appropriate.
Client testing checklist
- Valid header authentication returns the expected response.
- Missing credentials return
401. - Query-string credentials are rejected.
- Unapproved scopes or states return
403. - Malformed JSON and invalid field types return documented errors.
- Omitting
billing_dayspreserves backward-compatible base calculation. - Unsupported subsidy billing days fail closed with
422. - Historical FPPAS percentages are never applied as the current bill rate.
- The client respects rate-limit headers.
- Money arithmetic uses integer paise values where provided.
- The response
request_idis retained for troubleshooting. - Consumer-facing output preserves all monetary-scope limitations.
Required consumer-facing disclosure
Applications displaying an estimated amount should clearly distinguish it from an official utility bill.
“This estimate uses the verified tariff components currently released for the selected category. Any subsidy entitlement shown is units-only and does not reduce the amount. Historical FPPAS evidence is not a current applied rate. Monetary subsidy, current fuel or power-purchase adjustments, taxes, duties, meter rent, arrears, rebates and other bill components may change the final payable amount.”
Request API access
Use the secure API access request form for pilot, pricing, production or partnership discussions. Tell us the states, licensees, routes and expected traffic you need. Do not include an API key or consumer account data.
Maharashtra — State-Specific Developer Example
Explore one state-specific FY 2026–27 verified tariff implementation for MSEDCL, TPC-D, AEML and BEST using production-tested payloads.
Request JSON
cURL
YOUR_API_KEY with the API key issued to your
organisation. Never place API keys in query strings or public source code.
Integrate Power Expert India
Use the same electricity tariff, bill-verification and regulatory-intelligence layer through REST, SDKs or MCP. Tariff logic, evidence, verification status and release controls remain server-side.
/v1 endpoints and OpenAPI contract.Documentation, integration and policies
The earlier standalone onboarding page is superseded by this central portal. It may be redirected here after this page is verified.