BatteryArb handles public market data and customer inputs with separate risk assumptions.
This page explains how the product treats ISO public feeds, derived battery signals, contact and billing inputs, API keys, and operational logs.
Public market data
BatteryArb uses public ISO and RTO data sources, normalizes them, and computes derived outputs for battery use cases. Public source availability may affect freshness and coverage.
Customer-submitted data
Lead forms, billing email, and operational context submitted by customers are used only to support onboarding, billing, product evaluation, and support workflows.
Secrets and credentials
API keys are delivered by email and should be stored server-side. Public billing pages and demo flows are designed not to expose raw keys in the browser.
Logging and retention
Operational logs should exclude raw secrets and instead capture request metadata needed for reliability and abuse prevention. Retention should be limited to what is operationally necessary.
Customer recommendations
- Store BatteryArb keys in environment variables or a secret manager
- Proxy browser-facing requests through your own backend
- Rotate keys if exposure is suspected