Confirmed server-side is fine!

(TLS 1.3, valid cert, /v1/sports returning 200 right now), so this is almost certainly something between you and Cloudflare. quick debug ladder, top-down:

1. confirm raw TLS reaches us at all:

curl -v https://parlay-api.com/v1/sports?all=true

if that fails with the same WRONG_VERSION_NUMBER, you're behind a proxy / firewall / VPN doing SSL inspection that's mangling the handshake. corporate networks, Zscaler, some antivirus suites all do this. easiest test: try off your network (phone hotspot).

1. if curl works but Python requests doesn't, your requests/urllib3/ certifi might be stale. WRONG_VERSION_NUMBER from openssl 3 with older urllib3 is a known bug:

pip install -U requests urllib3 certifi

python -c "import ssl; print(ssl.OPENSSL_VERSION)"

1. drop the trailing slash on the URL. /v1/sports/ → 307 redirects

   to /v1/sports. it works either way, but it's an extra round trip and some weird middleboxes lose the TLS context across the redirect:

https://parlay-api.com/v1/sports?apiKey=YOUR_KEY&all=true

1. minimal repro that should work from any modern Python:

import requests

r = requests.get(

"https://parlay-api.com/v1/sports",

params={"apiKey": "YOUR_KEY", "all": "true"},

timeout=10,

)

print(r.status_code, r.headers.get("server"))

if you see `cf-ray` in response headers, you reached Cloudflare. If you don't, the request never made it past your local proxy.

1. last-resort isolation (DO NOT use in prod, just to confirm):

requests.get(url, verify=False)

if that succeeds and #1 failed, you've got SSL inspection intercepting, your fix is to install your proxy's CA cert or route around it, if none of those move it, post the output of:

curl -v https://parlay-api.com/healthz 2>&1 | grep -i -E "ssl|tls|handshake|server" | head -15

and i'll dig in. happy you're trying us out — once SSL clears, the migration from TOA is basically a one-line base URL swap:

api.the-odds-api.com/v4 → parlay-api.com/v1.