API Privacy & Logging Disclosure

This disclosure explains what operational information the Power Expert India Verified Tariff API processes, why it is used, how credentials are protected and how long runtime records are retained.

PEI API Privacy V1.0.0 Effective 18 July 2026 No plaintext API keys in request logs Privacy-safe operational logging

1. Scope

This disclosure applies to use of the Power Expert India Verified Tariff API, its dedicated API keys, public documentation and protected operational systems used to authenticate requests, enforce limits and investigate service issues.

It does not replace a separate privacy policy that may apply to the main Power Expert India website, contact forms, billing records or other products.

2. Information processed for API requests

The API may process and record limited operational metadata for each request:

Field Purpose Stored form
Timestamp Request sequencing, troubleshooting and retention Date and time
Request ID Traceability between responses and support investigations Random request identifier
HTTP method and route Usage analysis, abuse detection and debugging Examples: GET /health, POST /calculate
HTTP status and error code Monitoring authentication, input, rate-limit and runtime failures Examples: 401, 429, API_KEY_REQUIRED
Client key ID Rate enforcement and account-level troubleshooting Non-secret registry identifier, not the plaintext API key
Browser Origin CORS validation and browser integration support Normalised origin when an Origin header is present
Request duration Performance and reliability monitoring Milliseconds
Client network address Short-term security and abuse correlation Daily keyed hash rather than the raw address in the request log
User-Agent Operational compatibility and abuse review SHA-256 hash rather than the full value in the request log

3. What request logs are designed not to store

Dedicated API key plaintext is not intentionally written to request logs. The protected client registry stores a SHA-256 key hash rather than the plaintext credential.
  • API keys are rejected when placed in supported URL query-key names.
  • Request logs do not intentionally store raw tariff evidence bodies or protected server paths.
  • Request logs do not intentionally record full raw IP addresses or complete User-Agent strings.
  • The public API does not require a consumer’s name, postal address, phone number or electricity account number.

Clients should not send personal information in unsupported fields, headers, query parameters or calculation inputs.

4. Why operational information is used

  • authenticate API clients and enforce assigned scopes;
  • apply per-client state, CORS and rate-limit rules;
  • detect credential abuse, malformed traffic and service attacks;
  • investigate failed requests and provide technical support;
  • measure reliability, response time and capacity requirements;
  • maintain release traceability and security evidence;
  • comply with applicable legal or security obligations.

5. API credential protection

  • Dedicated keys are accepted only through supported request headers.
  • The protected registry stores SHA-256 hashes, key IDs, labels, scopes, allowlists, limits and lifecycle metadata.
  • A plaintext key is displayed only when a key is created or rotated and is not intended to be shown again.
  • Key rotation invalidates the previous credential immediately.
  • Revoked keys remain as non-secret audit records and cannot be re-enabled.
Clients remain responsible for secure secret storage and must not place live keys in screenshots, source repositories, browser code or support messages.

6. Retention and maintenance

The current operational retention policy is:

  • rate-limit state files: removed after approximately 2 hours when stale;
  • request logs: eligible for compression after 7 days;
  • request logs: eligible for deletion after 90 days;
  • API-key registry safety backups: newest 20 retained, with older excess backups eligible for deletion after 90 days;
  • maintenance reports: eligible for deletion after 180 days;
  • API-key administration audit logs: rotated at approximately 5 MB, retaining the newest 10 rotations.

Retention may be extended where reasonably required for an active security investigation, legal obligation, dispute or recovery event.

7. Browser origins and CORS

Browser-based requests may include an Origin header. The API normalises and compares that origin against the active client’s approved CORS allowlist. An origin may be recorded in operational logs to support security review and integration troubleshooting.

Server-to-server requests ordinarily do not send a browser Origin header.

8. Access, service providers and disclosure

Operational records are intended for authorised PEI personnel and systems that need them for security, infrastructure, support or compliance.

Hosting, storage, security or technical service providers may process limited operational data on PEI’s behalf where necessary to provide the service. PEI may also disclose information where required by applicable law, a valid legal process, or to protect users, clients, systems or rights.

PEI does not use API request logs as a public directory of clients and does not intentionally expose dedicated credentials to other API clients.

9. Security controls

  • HTTPS is required for production use.
  • API-key query parameters are rejected.
  • Client scopes, Bihar state access, CORS and rate limits are enforced.
  • Registry mutations use locking, validation, safety backups and atomic writes.
  • Maintenance runs use protected access and an exclusive execution lock.
  • Production artifacts are tracked by versioned SHA-256 freeze evidence.

No security method eliminates all risk. Clients should use least-privilege keys, bounded retries, secret rotation and appropriate monitoring in their own applications.

10. Client responsibilities

  • Do not send unnecessary personal information to the API.
  • Provide your own privacy disclosure where your application collects end-user data.
  • Restrict internal access to API keys and rotate exposed credentials promptly.
  • Preserve material base-tariff disclaimers in consumer-facing results.
  • Comply with applicable privacy, cybersecurity, consumer and contractual requirements.

PEI and the client may have separate roles for information collected by the client application. Those roles should be addressed in the applicable written agreement where required.

11. Account and privacy requests

An authorised client contact may request information about its configured key, ask for key rotation or revocation, or raise a concern about API operational data through the Power Expert India website contact channel.

PEI may require reasonable verification before acting on a request to protect the client account and other users.

12. Changes to this disclosure

This disclosure may be updated as the API, logging controls, hosting or retention policy evolves. The version and effective date at the top identify the active public disclosure.

13. Contact

Privacy, security and credential concerns should be submitted through the Power Expert India website contact channel. Do not include a live API key in the message.

This disclosure describes the current PEI API operational design. It should be reviewed by qualified legal counsel before large-scale paid or enterprise onboarding, especially where a client processes personal or regulated information.