Agent setup: authorize Sight MCP and ask your agent to call
get_tracking_setup. It configures this integration automatically.
Reverse proxies
Reverse-proxy setups for Sight's AI-agent-traffic feature — forwarding
the original User-Agent for crawlers (GPTBot, ClaudeBot, etc.) that
don't run JavaScript and won't fetch a <script src> tracker. One repo
covering four targets (Nginx, Caddy, Firebase Hosting, DigitalOcean App
Platform), per sightapp/sight-backend's tasks/plan.md (Track B5) —
a deliberate deviation from "one repo per platform" since these are
config snippets, not runnable packages.
The real constraint, stated plainly
Forwarding a crawler's page hit to Sight means POSTing a custom JSON
body ({"event_name":"pageview","path":...,"user_agent":...}) to
https://api.usesight.dev/api/v1/track with an X-API-Key header —
conditionally, only for known AI-agent UAs. Plain reverse-proxy
declarative config (a Caddyfile, a stock nginx.conf) has no way to
construct an arbitrary JSON body — that needs either a scripting
extension, or a small companion app doing the actual POST (exactly what
sight-express,
sight-flask, etc. already
are). This repo is honest about which is which per target, rather than
inventing declarative syntax that doesn't exist.
Nginx — nginx/
Real solution: the official njs module (ngx_http_js_module, ships
with nginx.org packages) can run a small JS function per request. See
nginx/sight-crawler.njs +
nginx/nginx-snippet.conf.
Plain static site (HTML/JS files served by nginx, no app behind it):
this is the setup for you. ChatGPT-User and other browsing agents read
only the HTML — they never run the <script> tracker — so nginx must
report the hit itself. Point @sight_origin at your files (root +
try_files), not proxy_pass. SIGHT_API_KEY can be the same pk_
collection key as the browser snippet (the njs script sends a Referer
so a domain allowlist still passes) or an sk_ key.
Caddy — caddy/
Caddy's core has no scripting for custom request bodies without a
compiled-in plugin (xcaddy). The practical pattern: a Caddyfile
matcher routes crawler UAs to a tiny companion app (e.g. sight-express)
running alongside your site, which does the actual POST to Sight. See
caddy/Caddyfile.
Firebase Hosting — firebase-hosting/
Firebase Hosting has no request scripting at all — firebase.json
rewrites can route matching paths to a Cloud Function, which does the
UA check + POST. See
firebase-hosting/firebase.json +
firebase-hosting/functions/index.js.
DigitalOcean App Platform — digitalocean/
App Platform's app.yaml can route a path prefix to a second component
(a tiny Node service doing the same UA-check-and-POST) alongside your
main app. See digitalocean/app.yaml.