Client reads ZOO_AI_TOKEN instead of ZOO_API_TOKEN; env-based auth never reaches requests

[sneg55]

TypeScript client reads ZOO_AI_TOKEN instead of the standard ZOO_API_TOKEN, and endpoint helpers never read the environment at all

Context: API Makeathon participant. Found reviewing the official clients.

Two related authentication defects mean a user who follows the README, with the standard ZOO_API_TOKEN env var set, sends unauthenticated requests.

1. Wrong env var name (typo)

src/client.ts:57:

const envToken = env?.KITTYCAD_TOKEN || env?.KITTYCAD_API_TOKEN || env?.ZOO_AI_TOKEN

The ecosystem standard is ZOO_API_TOKEN, used by the Rust SDK (kittycad.rs/kittycad/src/lib.rs), the zoo CLI (cli/src/context.rs), the Python SDK, and this repo's own CI (.github/workflows/CI.yml sets ZOO_API_TOKEN). ZOO_AI_TOKEN is defined nowhere. grep -rn "ZOO_API_TOKEN" src/ matches only comments; the string is read nowhere in the TS source.

2. Endpoint helpers ignore the environment entirely

The README shows calling an endpoint (e.g. create_file_mass) without constructing a Client, relying on an env token. But endpoint helpers read auth only from client?.token; they never construct a default Client or read the environment. So the documented env-only usage sends no Authorization header regardless of which env var is set.

Concrete failure

A user exports ZOO_API_TOKEN (which works for the CLI, Python, Rust, and Go), runs the README's TS example or new Client(), and every request comes back 401. Baffling, because the same environment authenticates every other Zoo tool.

Suggested fix

Add ZOO_API_TOKEN to the env fallback in client.ts (keep the others for back-compat), and either make endpoint helpers fall back to a default env-configured Client or fix the README to always construct one.

Verify

Evaluate the constructor's env expression with only ZOO_API_TOKEN set; the token resolves to undefined. grep -rn "ZOO_API_TOKEN" src/ returns only comment lines.

Environment

Reviewed against the current main of KittyCAD/kittycad.ts.