API returns Cloudflare 403 challenge for requests originating from Cloudflare Workers (server-to-server blocked)

[mfzeidan]

Summary

Requests to api.opengolfapi.org from Cloudflare Workers receive a Cloudflare bot-challenge page (HTTP 403 + challenge HTML) instead of JSON. The same requests succeed from residential IPs, GitHub Actions runners, and browsers.

This blocks any backend integration hosted on Workers (and likely other datacenter egress), which conflicts with the docs' encouragement to build server-side on the API.

Reproduction

From a deployed Cloudflare Worker:

const res = await fetch("https://api.opengolfapi.org/v1/courses/search?q=Algonkian&state=VA", {
  headers: { Accept: "application/json", "User-Agent": "gonkbot/1.0 (+https://gonkbot.com)" }
});
console.log(res.status); // 403, body is the Cloudflare challenge HTML

Same URL via curl from a residential IP: 200 with the expected course JSON.

• Setting a descriptive User-Agent does not help.
• Observed against /v1/courses/search; presumably zone-wide.

Expected

JSON responses (or at worst a structured 403/429 JSON error per your error contract) for API traffic regardless of egress network — the API is documented as keyless for reads.

Suggested fix

Exempt the API hostname from Bot Fight Mode / managed challenge (or add a WAF skip rule for api.opengolfapi.org). Challenges are unanswerable for non-browser clients, so any challenge on an API hostname is effectively a hard block.

Happy to test a fix — we integrated OpenGolfAPI into a golf MCP server (course import + weather at round finish) and it works great everywhere except Workers-to-API.

Also: does an X-API-Key on requests bypass the rule? If so, documenting that would help other server-side integrators.

[mfzeidan]

Additional data point: sending a valid developer key (X-API-Key) does not bypass the challenge — expected, since the WAF challenge fires before the Worker sees the request. So server-side integrators currently have no workaround other than non-datacenter egress. A WAF skip rule on the api hostname would resolve it entirely.