Plenty of enterprise Claude applications live in Node.js — web backends, Cloud Run services, internal tools built by full-stack teams. Anthropic supports this path on Vertex AI with an official TypeScript SDK. The important thing to get right up front is which package: for Vertex AI, Anthropic's documentation points to a dedicated package, @anthropic-ai/vertex-sdk, installed with:
npm install @anthropic-ai/vertex-sdkYou may see references to the general-purpose @anthropic-ai/sdk package elsewhere; that is the first-party client, keyed to Anthropic API keys. The Vertex package exists precisely because authentication and routing on Vertex are different — check the official documentation for the current relationship between the two packages before standardizing.
Authentication: no API key, just Google credentials
The TypeScript SDK does not take an Anthropic API key. Per Anthropic's docs, it "goes through the standard google-auth-library flow" — Google's official Node.js authentication library, which discovers Application Default Credentials (ADC) from the environment. In practice that means:
On a developer laptop: run gcloud auth application-default login once. The SDK picks up your user credentials automatically.
In production on GCP: attach a service account to the workload (Cloud Run, GKE, Compute Engine) with the Vertex AI User role (roles/aiplatform.user), which carries the aiplatform.endpoints.predict permission needed to call the model. No key file needs to ship in your container. See service account authentication for the production patterns.
Like the Python client, the Node client needs to know your Google Cloud project and a region value — "global" for the dynamically routed global endpoint, "us"/"eu" for multi-region, or a specific region such as "us-east1". Regional and multi-region endpoints carry a 10% price premium over global for Sonnet 4.5 and later models.
What the request and response look like
The API surface mirrors the Anthropic Messages API: you call a messages.create-style method with a bare model ID (claude-sonnet-5, claude-opus-4-8 — no anthropic. prefix on this platform), a max_tokens value, and a messages array that alternates user and assistant roles, starting with user. Responses come back in the standard Messages shape — a content array of typed blocks — with one Vertex-specific tell: message IDs are prefixed msg_vrtx_.
Two wire-level differences from the first-party API are worth knowing even though the SDK hides them: the model name travels in the endpoint URL rather than the request body, and anthropic_version is a body field that must be "vertex-2023-10-16". If you ever bypass the SDK and call the REST endpoint (:rawPredict for synchronous calls, :streamRawPredict for server-sent events), you'll need to handle both yourself — one more reason to stay on the SDK.
Limits and platform gaps that affect Node apps
Request payloads are capped at 30 MB, with images limited to 5 MB per file and 100 per request — relevant if your Node service proxies user uploads straight into Claude. And the feature gaps that apply to Vertex AI apply regardless of language: no Anthropic Message Batches API, no Files API, no server-side code execution or web fetch tools. Client-implemented tools (tool use with your own functions) work fine, which is usually the natural pattern in a Node backend anyway.
Before any of this runs, the platform prerequisites must be in place: Vertex AI API enabled on the project, billing active, and each Claude model enabled from its Model Garden card. Those steps are console-side, not code-side — the project preflight checklist walks through them.
Where to go next
The Python equivalent is covered in the AnthropicVertex Python SDK guide, and common Vertex errors is worth bookmarking before your first deployment. For deployment patterns, see deploying on Cloud Run.