The proxy

One core is assembled from per-concern modules and imported from one place by all three hosts, so the route table is the same in dev, on a Node server and on Vercel.

The routes

Paths are the defaults; every one of them is an option.

POST /chatfuel/auth/provision and the three bots routes are mounted on the gate and the service-role key; CHATFUEL_WORKSPACE_ID is checked inside the handler, so a deployment missing it gets an answer that names the variable rather than a 404.

What decides whether a route exists at all

A route that is not mounted is not claimed: the dispatcher returns false, the host answers its own 404, and that 404 is the signal. The app reads a 404 on the publishing routes as "this deployment keeps its queue in the browser" and offers no schedule control. A deployment that never asked for a panel answers 404 on /chatfuel/admin and the app reads that as "no panel".

The one exception is a password that is set but shorter than 16 characters: adminMode becomes misconfigured, the routes stay claimed, and they answer 500 — a panel that quietly is not there teaches the operator nothing.

Under /chatfuel/admin

Every path except /session requires a signed cf_admin cookie and an x-cf-admin request header — a form posted from another origin can send a cookie but cannot set a header. The cookie is minted from ADMIN_PASSWORD, lasts 12 hours, and is the whole authorization: this module never calls admitRequest, never consults the auth gate and never applies the workspace fence, because the panel's purpose is the account-wide view those exist to withhold.

Anything else under the prefix is 404 AdminRouteNotFound.

Under /chatfuel/publishing

The options

createChatfuelProxy(options, env) takes these; each falls back to the env bag, then to a default.

auth resolved from env has three outcomes: both VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY set is on, neither is off, and exactly one is misconfigured — which fails closed, so every proxied request answers 500. See the auth gate for what the gate then does, and the environment for where the variables come from.

The three hosts

A rewrite straight to panel.chatfuel.com would be cheaper and cannot work: a rewrite forwards the browser's headers and has no way to add one, so the token would have to be sent by the client — the one thing the proxy exists to prevent. The headers block in vercel.json sets response headers, not request ones.

Nothing the client sent is forwarded

Outgoing headers are built from scratch rather than merged, so the browser's Authorization and its cookies are stripped by construction:

• The GraphQL forward sends exactly content-type: application/json and authorization: Bearer <token>.
• The REST passthrough sends authorization plus the request's content-type when there is one, because a multipart upload needs its boundary. Nothing else, cookies included, travels.
• The WebSocket relay waits for the browser's connection_init, gates it, and then sends its own connection_init {authToken: "Bearer …"} upstream. The browser's payload — the user's session JWT — is consumed by the gate and never leaves the server.

Coming back the other way, the upstream status and body pass through untouched, because a GraphQL refusal arrives as an envelope under HTTP 200 and rewriting it would lose the answer. The proxy's own refusals are no-store: a cached 403 would keep saying "not your bot" about a bot that has since become the caller's. Which codes those are is on the errors page.