Privacy

Plain, specific, and true to this codebase - not a compliance template.

No accounts

There is no signup and no login for API callers. Nothing to register, no API key to leak. Payment is the only thing that authorizes a paid call - a valid x402 payment on a request is treated the same regardless of who sent it. The only login on this service is the operator's own admin dashboard at /admin, which exists for us to check on the fleet - it has nothing to do with API callers and callers never need it.

Payments

Paid routes are settled via x402 in USDC on Base. On-chain payments are public by nature - anyone can look up a settled transaction on a Base block explorer once it happens; that visibility comes from the blockchain, not from us. We do not treat a wallet address or a signed payment payload as a caller's identity, and we don't build any profile from them. When a payment settles, its transaction hash, the charged amount, and whether it settled are written to our request log purely as an operational receipt (so we can answer "did this call actually get paid for") - not linked to a name, an account, or a session, because none of those exist here.

What request logs contain

Every request writes one operational log row: HTTP method and path, response status code, whether the route was free or paid, the monitor slug involved (if any), whether a 402 challenge was issued, settlement outcome and transaction hash (paid routes only), an error message when a request failed, and how long it took. That's it - no names, emails, organizations, or account identifiers, because callers never provide any. Client IP addresses are not written to this application's database. We can't speak to what the underlying hosting infrastructure or its network-level rate limiting sees or retains at the transport layer - that's outside this application's code.

Retention

Request logs are kept for 90 days. A scheduled sweep deletes anything older once a day. This is best-effort housekeeping, not a guaranteed real-time erasure: if a sweep fails it logs the failure and simply tries again on its next run, so a row could in principle outlive 90 days briefly if cleanup was interrupted.

Where vendor data comes from

Everything this API sells is built from vendors' own public status pages - the same pages anyone can open in a browser. For vendors with a machine-readable feed, we call it directly. For the rest, a headless browser opens the public status page on a schedule and reads its visible text, which is then turned into the same structured shape. What we keep is a structured snapshot (overall status, components, active incident) plus a fingerprint and the resulting change history - not a permanent copy of the full page body or raw HTML.

Admin dashboard

The operator dashboard at /admin is password protected and deliberately kept out of search engines - it's not linked from any public page here. It shows operational figures aggregated from request logs and monitor state: traffic broken down by free calls, paid calls, and payment prompts; settled revenue for all time and rolling 24-hour/7-day/30-day windows (and revenue per vendor); the busiest paths and most recent real failures (never payment prompts); monitor status and check history per vendor; and whether the payment facilitator itself is currently reachable. Every one of those figures is a count or a sum over the request-log fields already described above - the dashboard has nothing to identify an individual API caller with, because we don't collect anything that would let it.

Contact

Questions about this policy or how the service handles data can go to statusstateapi@proton.me, or the operator's GitHub profile.

Honest close

This is a small, independently operated service. There's no compliance certification, no formal data-subject request process, and no privacy team - just the operator reading mail. If this page ever stops matching what the product actually does, the page changes.