Privacy

Plain, specific, and true to this codebase - not a compliance template. Last updated September 21, 2026.

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 or Solana. On-chain payments are public by nature - anyone can look up a settled transaction on the block explorer for whichever chain paid it, once it happens; that visibility comes from the blockchain, not from us.

We do not store the payer's wallet address. There is no column for one. What a settled call records is the facilitator's receipt - that it settled and the settlement transaction hash - alongside the price that was in effect for that call. Our settlement scheme's receipt reports no amount of its own, so that field stays empty in practice and revenue is summed from the recorded price instead. The signed payment payload a caller sends is passed to the facilitator to be verified and settled; it is not written to our database or our application logs.

One honest consequence of the above: the transaction hash we do store is a public pointer. Anyone holding it can resolve the addresses involved on a block explorer - that is simply what settling on a public chain means. We just don't keep the address ourselves, we don't treat a wallet or a signed payload as a caller's identity, and we build no profile from either.

What request logs contain

A request that reaches our logging layer attempts one operational row: a request id, the HTTP method, the path (without any query string), the response status code, whether the route was free or paid, the monitor slug when the request actually matched a tracked vendor, whether a 402 payment challenge was issued, whether payment settled, the settlement transaction hash, which chain it settled on, and the amount the facilitator reported, the price in effect for a paid call, an error message when one was recorded, how long the request took, and when it happened. Anything turned away before that point - a malformed body rejected by the parser sitting in front of it - is never logged here at all. The write itself is fire-and-forget: if it fails, the failure is logged on our side and the row is simply lost, never retried and never allowed to affect the response you already got.

We never ask for a name, email, organization, or account identifier, and the table has no field for one - there are no accounts here to attach them to. One caveat, stated plainly rather than glossed: the path is stored as it was requested, and when a request names a vendor that doesn't exist, the rejected slug is quoted back in the stored error message. So whatever a caller chooses to put in the URL is what lands in those two fields. Beyond the method and the URL itself, nothing in the row comes from the caller.

Client IP addresses are not written to this application's database - the table has no column for one. The application's own HTTP request logging is deliberately narrow too: request id, method, path without query string, status code, and how long the response took, with authorization and cookie headers redacted. The rest of what this service logs is operational - monitor checks, scheduler activity, failures - not caller data. What the underlying hosting infrastructure or its network-level rate limiting sees or retains at the transport layer is outside this application's code, and we can't speak for it.

Retention

Request logs are kept for at least 90 days. A sweep runs when the service starts and once a day after that, deleting rows past that age - but only within the span a stored summary already covers, which makes 90 days a floor rather than a ceiling.

Aggregate operator reports are kept permanently. Once a 90-day period closes, a summary PDF of that window is generated - counts, revenue totals, per-vendor and per-path request tallies - and kept indefinitely. It holds no request-level rows and no identity fields, because the logs behind it have none either; what it does carry from them is aggregate request paths, with whatever those paths themselves contained. Raw log rows are only deleted once the period covering them has that stored summary; where a report is missing or failed, deletion stops there and those logs stay until it exists.

Two consequences worth stating plainly. Rows written before the first reporting period began sit outside that grid entirely, so no summary stands in for them and they are never swept. And this is best-effort housekeeping, not guaranteed real-time erasure: a failed sweep logs the failure and tries again on its next run.

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 broken down per vendor and per settlement chain); 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. There is no identity or account field for it to show, because none is collected - but the caveat above applies here too: the busiest paths and recent failures it lists are stored paths and stored error messages, so anything a caller put in a URL can surface there as well.

Third parties

A few outside parties can handle technical data for this service to work at all: the x402 facilitator, which receives a paid call's payment payload because verifying and settling it is what taking payment requires; the email delivery provider used for the operator's own alerts (see Operational alerts below); and the hosting provider (Replit; see Hosting infrastructure below), which processes the traffic needed to serve HTTP. Each does so under its own terms. This page describes what this service itself stores.

Operational alerts

When something needs a human's attention - a scheduler stall, critical container memory, or one vendor's checks failing or stuck on "unknown" - this service can notify the operator by email through Resend, an email delivery provider, sent to an address the operator configures outside of this codebase. That email contains only the operational fact that tripped the alert - a vendor slug, a sweep id, a memory reading, an internal error message - the same kind of detail already described under Admin dashboard above. None of these conditions originate from a caller's request, so no caller data can appear in one.

This deployment currently has an alert destination configured, so this delivery is active.

Hosting infrastructure

This service runs on Replit, which adds protections that hold independently of this application's own code. Replit runs each deployed app's compute, secrets, and storage in a dedicated, single-tenant Google Cloud Platform project - not shared with any other customer's application. Traffic is served over HTTPS with TLS 1.2+ and Replit-managed certificates, and data at rest is AES-256 encrypted. This application's own secrets - database credentials, the payment facilitator's configuration, the admin password - are stored in Replit's encrypted secrets manager and injected as environment variables at runtime; they are never committed to source control, never written to application logs, and never returned in an API response.

Replit, as the platform operator, holds a SOC 2 Type II attestation of compliance and runs automated vulnerability scanning and web application firewall protection at the infrastructure layer. These are facts about the platform this application runs on, not a certification of this application itself - they sit beneath, and do not replace, the data-handling practices described elsewhere on this page.

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.