Here are some suggestions from AI:
- Anonymous session token blocked by cookie/storage restrictions. Many of these chat widgets silently mint a session ID (cookie or localStorage) on first load and attach it to every API call. If a colleague's browser blocks third-party cookies or storage (Safari/Firefox tracking protection, private/incognito mode, corporate-managed browser policy, or an extension like uBlock/Privacy Badger/Brave Shields), that token never gets created or sent — the API call then looks like an unauthenticated request and gets rejected as "unauthorised."
- Origin/Referrer check failing. If the backend validates that requests come from paratext.org itself (a common lightweight anti-abuse measure instead of real auth), anything that changes how the page is loaded — a corporate web filter/proxy that rewrites or strips headers, a translation proxy, "Reader mode," or opening the link inside another app's in-app browser — can break that check even though the page renders fine.
- Corporate proxy/SSL inspection stripping headers. SIL-affiliated colleagues are often on managed networks with deep packet inspection or content filtering that strips Authorization, Cookie, or custom headers on outbound API calls, while the chat UI itself still loads normally from a CDN.
- Shared backend API key hitting a rate/quota limit. If the widget proxies to something like Claude's API using one shared server-side key, a burst of simultaneous demo traffic (you + 3 colleagues all firing prompts within a minute) could trip a rate limit that the backend reports as "unauthorised" rather than "too many requests."
Fastest way to confirm: have one colleague open browser DevTools → Network tab, retry a prompt, click the failed request, and check the actual HTTP status code (401 vs 403 vs 429) and response body — that will tell us definitively which of these it is. If you can grab that, I can pin down the cause precisely.
