# Wattwatchers > Wattwatchers is an Australian digital energy company (founded 2007, Sydney NSW) that makes the Auditor family of DIN-rail electricity monitoring and switching devices and runs the cloud platform behind them. It sits behind the meter, not at it: Auditors clamp onto individual circuits and report real-time, circuit-level energy data over 4G or WiFi. The REST API v3 ("Mercury") is the delivery mechanism for that data. Documentation, a live Swagger UI and the OpenAPI 3.0 contract are all served anonymously; API keys are not — Wattwatchers issues each bearer token by hand and scopes it to the devices you own. Wattwatchers was acquired by EPX Limited (ASX:EPX) in 2026. Generated by API Evangelist from apis.yml and the artifacts in this repository. Wattwatchers does not publish an llms.txt of its own (https://docs.wattwatchers.com.au/llms.txt returned 404 on 2026-07-27). ## Quick facts - API: Wattwatchers REST API v3 (Mercury), version 3.6.0 - Base URL: https://api-v3.wattwatchers.com.au - Auth: `Authorization: Bearer key_...` — a Wattwatchers-issued API key, scoped to a fixed device set. No OAuth, no OIDC, no scopes, no self-serve signup, no sandbox. - Surface: 13 paths / 14 operations. 13 safe reads and one write (`PATCH /devices/{device-id}`), which can switch a physical relay. - Events: none. No webhooks, MQTT, WebSocket or SSE. Integrators poll. - Errors: proprietary `{code, httpCode, message}` envelope over `application/json` — not RFC 9457. - Rate limits: per-key TPS and TPD, auto-scaled by device count, signalled in `X-RateLimit-Tps*` / `X-RateLimit-Tpd*` headers. ## APIs - [Wattwatchers REST API v3 (Mercury)](https://docs.wattwatchers.com.au/api/v3/index.html): Device inventory and configuration (including switch control via PATCH), 30-second "short energy" interval data, 5-minute "long energy" interval data, and Modbus register data read from downstream equipment by 6M+One hardware. ## Specs - [OpenAPI 3.0.0 (upstream)](https://docs.wattwatchers.com.au/api/v3/openapi/public_rest_api_3_6_0.json): the published contract, version 3.6.0. - [OpenAPI (harvested)](openapi/wattwatchers-rest-api-v3-openapi.json): verbatim copy held in this repository. - [Overlay](overlays/wattwatchers-rest-api-v3-overlay.yaml): API Evangelist enhancements over the published spec. ## Docs - [Documentation hub](https://docs.wattwatchers.com.au/) - [REST API v3 overview](https://docs.wattwatchers.com.au/api/v3/index.html) - [Endpoint reference](https://docs.wattwatchers.com.au/api/v3/endpoints.html) - [Interactive Swagger UI](https://docs.wattwatchers.com.au/api/v3/openapi/index.html) - [Authentication](https://docs.wattwatchers.com.au/api/v3/auth.html) - [Conventions](https://docs.wattwatchers.com.au/api/v3/conventions.html) - [Errors](https://docs.wattwatchers.com.au/api/v3/errors.html) - [Rate limits](https://docs.wattwatchers.com.au/api/v3/rate-limits.html) - [Release notes](https://docs.wattwatchers.com.au/api/v3/release-notes.html) - [Roadmap](https://docs.wattwatchers.com.au/api/roadmap.html) - [Phase grouping](https://docs.wattwatchers.com.au/api/v3/phase-grouping.html) - [Differences between v2 and v3](https://docs.wattwatchers.com.au/api/v3/v2-diff.html) - [6MW differences](https://docs.wattwatchers.com.au/api/v3/6mw-diff.html) - [Using the OpenAPI specification](https://docs.wattwatchers.com.au/api/tips/openapi-spec.html) ## Tips - [Concepts](https://docs.wattwatchers.com.au/api/tips/concepts.html) - [Polling data from the API](https://docs.wattwatchers.com.au/api/tips/polling-data.html) - [Device catch-up](https://docs.wattwatchers.com.au/api/tips/device-catch-up.html) - [Modbus data](https://docs.wattwatchers.com.au/api/tips/modbus-data.html) - [Units conversion](https://docs.wattwatchers.com.au/api/tips/units-conversion.html) - [Working with timestamps](https://docs.wattwatchers.com.au/api/tips/working-with-timestamps.html) - [Switching example](https://docs.wattwatchers.com.au/api/tips/switching-example.html) ## Artifacts in this repository - [Authentication profile](authentication/wattwatchers-authentication.yml) - [API conventions](conventions/wattwatchers-conventions.yml) - [Error code catalog](errors/wattwatchers-error-codes.yml) - [Rate limits](rate-limits/wattwatchers-rate-limits.yml) - [Lifecycle and versioning](lifecycle/wattwatchers-lifecycle.yml) - [Changelog](changelog/wattwatchers-changelog.yml) - [Data model](data-model/wattwatchers-data-model.yml) - [Standards conformance](conformance/wattwatchers-conformance.yml) - [Packages](packages/wattwatchers-packages.yml) - [Candidate MCP tool surface](mcp/wattwatchers-mcp.yml) - [Agent skills](skills/_index.yml) - [Domain security probe](security/wattwatchers-domain-security.yml) - [Well-known probe results](well-known/wattwatchers-well-known.yml) - [Request/response examples](examples/wattwatchers-rest-api-v3-examples.json) ## Code - [rest-api-notebooks](https://github.com/wattwatchers/rest-api-notebooks): first-party Jupyter notebooks for Long Energy and Modbus downloads. - [le_completeness_analysis](https://github.com/wattwatchers/le_completeness_analysis): first-party notebook analysing Long Energy interval completeness. - No client SDK is published. Wattwatchers direct developers to generate a client from the OpenAPI contract. ## Apps and support - [Fleet Management app](https://fleet.wattwatchers.com.au) — where an existing customer's API key is displayed. - [Onboarding app](https://onboarding.wattwatchers.com.au) — installer device configuration. - [Knowledge base and support tickets](https://service.wattwatchers.com.au/) ## Notes for agents - Energy payloads are POSITIONAL arrays indexed by channel order. Call `getDevice` first; `eReal[n]` corresponds to `channels[n]`. Never label energy data without the device record. - HTTP 204 means the device has never reported that data class. HTTP 200 with `[]` means it has data but none in your requested window. These are different states. - Time windows are capped: 12 hours for Short Energy, 7 days for Long Energy at default granularity. Exceeding the cap returns 422, not a truncated result. - `timezone` is required when `granularity` is `hour` or coarser. - `fields[energy]=+pf` cannot be combined with `filter[group]=phases`, nor with `fields[energy]=timestamp`. - Configuration writes are eventually consistent: the requested value appears under `pending` until the device connects and converges. - `PATCH /devices/{device-id}` can open or close a physical relay on +3SW hardware. Treat it as a safety-relevant action and confirm with a human. - Devices buffer during comms outages and back-fill on reconnect; catch-up can take up to ~6 hours. Track a per-device "last Long Energy received" watermark rather than polling a rolling window.