Diagnose an ISP-Level Block in 60 Seconds

Posted 2026-05-19. 4 steps, 1 minute, no auth, no signup.

If parlay-api.com isn't loading for you, the question is almost always one of two things: is the API down, or is something on your network filtering us? The four steps below give you the answer in about a minute and decide which fix to try.

Short version. Open /diag, click Run, read the ISP reachability panel. If your ISP shows reachable_recent for other customers, the issue is local to your machine. If it shows no_recent_requests for 24 hours or more, the ISP is filtering us and you need a DNS swap or VPN.

The 4-step workflow

Open the diagnostic page Visit https://parlay-api.com/diag on the network you suspect is being filtered. If the page itself won't load at all (timeout, captive-portal redirect, "suspicious site" interstitial), skip ahead to the workarounds; you have a clear filter-level block.
Run the diagnostic Click Run diagnostic. Seven probes fire in parallel: TLS, several JSON endpoints, the new /v1/meta/isp-reachability snapshot, and a static-asset fetch. Total runtime is under 3 seconds on a healthy network.
Read the ISP reachability panel Scroll to the panel labeled ISP reachability right now. The JSON lists 9 major US ISPs and the request count we have seen from each in the past 24 hours. Two readings to look for:

"status": "reachable_recent" with a non-zero request_count_24h means other customers on your ISP are reaching us as you read this. Your problem is local: a device DNS setting, a corporate VPN, an antivirus web filter, or a captive portal.

"status": "no_recent_requests" with a populated known_filter_history array means we have documented complaints about this ISP filtering us and we are pursuing reclassification.
Apply the right workaround Local problem: change your device's DNS to 1.1.1.1 (Cloudflare) or 9.9.9.9 (Quad9), disable any corporate VPN you have on, or try a different browser profile with no extensions. ISP-level filter: same DNS swap usually works because most "Security Shield"-style filters operate at the recursive DNS layer. Failing that, route through Tailscale or a commercial VPN. Read the full background piece for the long-term fix: When Your ISP Blocks a Sportsbook API.

Why the ISP-reachability endpoint exists

We built /v1/meta/isp-reachability because the single most useful piece of information when triaging an unreachability report is whether other customers on the same ISP are reaching us right now. If they are, the customer's local config is the problem. If they aren't, the ISP is the problem and the workaround set is completely different.

The endpoint is public, no-auth, and free. It returns, for each of 9 major US residential and business ISPs (Spectrum, Comcast, Verizon FiOS, AT&T, Cox, CenturyLink, Frontier, T-Mobile Home Internet, Starlink), an exact count of requests we have observed in the past 24 hours, when we last saw one, and a status bucket. It also classifies your own IP against the same CIDR list and surfaces our documented filter history per ISP so you can see the current state without chasing a separate doc.

Counts are not estimates. They are exact, in-memory, observed request totals since the worker booted. We do not extrapolate, derive, or smooth them.

Operator notes

The 9-ISP CIDR list covers the largest US consumer and business circuits. International ISPs are not yet tracked.
Counts reset on worker rolling-reload (every deploy). After a reset, expect the panel to show no_requests_observed_since_process_start for several minutes until traffic resumes.
Currently the load balancer routes you to a single worker per request, so two consecutive calls can return slightly different snapshots if they land on different workers. Poll a handful of times to see the cluster shape.
If you find yourself on an ISP that has us blocked and the documented workarounds aren't enough, email support@parlay-api.com with the JSON output from your /v1/meta/isp-reachability call. The data tells us exactly which ISP feeds need reclassification next.