OpenWikianthropics/anthropic-sdk-typescript

Installation and Requirements

Purpose and Scope

Use this page when you are adding the official Anthropic TypeScript SDK to a server-side JavaScript or TypeScript project and need to confirm the supported installation path, runtime baseline, and package shape. The primary package is published as the public npm package for direct Claude API access, and the repository README positions it as the SDK for using the Claude API from server-side applications. That framing matters because the default security posture assumes private API credentials are kept off untrusted clients rather than embedded in browser bundles.

Sources: README.md, package.json

The minimum successful setup has three parts: install the npm package, provide an Anthropic API key through your application configuration, and run the code in a supported JavaScript runtime. The README example imports the default client, constructs it with an API key that normally comes from the environment, and calls the Messages API. For a new integration, treat installation and runtime validation as the foundation before exploring higher-level SDK features such as streaming, tools, structured outputs, files, or Managed Agents.

Sources: README.md

Relevant Source Files

  • README.md — Documents the public package purpose, installation command, starter client example, TypeScript support level, runtime support matrix, browser warning, and React Native limitation.
  • package.json — Defines the npm package name, version, public publishing metadata, entrypoints, dependency and peer dependency expectations, CLI binary name, and package export map.
  • tsconfig.build.json — Shows how the distributed build emits declarations, declaration maps, JavaScript output, and source maps from the generated distribution source tree.
  • tsconfig.deno.json — Shows the Deno-oriented type-checking configuration, including the Deno distribution tree, DOM library support, and no-emit behavior.

Install the Primary SDK

Install the primary SDK from npm with the package name shown in the README. This is the package to use for the direct Claude API hosted by Anthropic, not a provider-specific wrapper for Amazon Bedrock, Google Vertex AI, or Microsoft Foundry. The repository package metadata confirms the same package name and describes it as the official TypeScript library for the Anthropic API. In normal Node package managers, adding the dependency makes the default client import available from the root module.

Sources: README.md, package.json

npm install @anthropic-ai/sdk

After installation, create a client in application code and send a first Messages request. The README demonstrates a default import named Anthropic and an API key sourced from the environment. The comment in the example states that the environment-based API key is the default and can be omitted from the constructor. That means many applications can centralize credential loading in deployment configuration, while still passing the key explicitly in tests, scripts, or multi-tenant setups where each request chooses different credentials.

Sources: README.md

import Anthropic from '@anthropic-ai/sdk';
 
const client = new Anthropic({
  apiKey: process.env['ANTHROPIC_API_KEY'],
});
 
const message = await client.messages.create({
  max_tokens: 1024,
  messages: [{ role: 'user', content: 'Hello, Claude' }],
  model: 'claude-opus-4-6',
});
 
console.log(message.content);

Core Primitives

For installation planning, the core primitive is the exported Anthropic client. It is the object that owns configured authentication and exposes generated resource groups such as messages. A resource group is a typed API surface for a family of Claude endpoints; the README example uses the messages resource to create a model response from a list of conversation messages. The package metadata publishes both CommonJS and ECMAScript module entrypoints, so applications can import the same package from either module system according to their build configuration.

Sources: README.md, package.json

The second primitive is the runtime environment. The SDK is intended for server-side TypeScript or JavaScript applications, and the README lists supported runtimes explicitly. The runtime determines whether standard networking, environment variables, stream behavior, and credential handling work as expected. Browser execution is intentionally disabled by default because an API key in browser code can be exposed to end users. If a project truly requires browser execution, it must opt in deliberately with the documented browser option rather than relying on accidental bundler behavior.

Sources: README.md

The third primitive is the generated type distribution. The root package declares TypeScript definitions through the package metadata, while the build configuration enables declarations and declaration maps. That combination is important for editor autocomplete, compile-time request checking, and navigation from published types back to source-mapped declarations. The Deno configuration separately type-checks a Deno distribution tree with an ES2020 and DOM library target while using no emit, which signals that Deno support is validated as a distinct distribution concern rather than only through Node-style packaging.

Sources: package.json, tsconfig.build.json, tsconfig.deno.json

Runtime and TypeScript Requirements

The README states that TypeScript version 4.9 or newer is supported for the primary package. The repository itself develops with a newer TypeScript dev dependency, but consumers should follow the public compatibility statement when choosing a compiler baseline. If your application is pinned below that level, upgrade the compiler before depending on the SDK types. This is especially important for projects that enforce strict type checking in continuous integration, because request and response models are part of the package value rather than incidental documentation.

Sources: README.md, package.json

The supported runtime list covers Node.js 20 LTS or later non-end-of-life versions, Deno 1.28.0 or higher, Bun 1.0 or later, Cloudflare Workers, Vercel Edge Runtime, Jest 28 or greater with the node test environment, and Nitro 2.6 or greater. The Jest qualification is specific: the node environment is supported, while jsdom is not supported at this time. React Native is also not supported. When debugging unexplained behavior, first verify that the integration is not running under an unsupported test or mobile runtime.

Sources: README.md

Browser support deserves a separate decision because it changes the threat model. The README says web browsers are disabled by default to avoid exposing secret API credentials and points readers toward API key best practices. A backend service, serverless function, worker, or edge runtime is usually the safer place to call Claude directly. If a browser client needs Claude-powered behavior, route the request through a server component that holds the secret, validates user intent, and enforces any application-specific limits before forwarding the request.

Sources: README.md

Package Shape and Build Signals

The package metadata identifies the root package as public, licensed under MIT, and published with a CommonJS package type while also exporting ESM builds. The root export maps import consumers to a module build and require consumers to a CommonJS build. It also provides wildcard exports for JavaScript and module files under the built distribution. These details are useful when configuring bundlers, test runners, or monorepo package resolution because they explain why both import styles are expected to work from the same installed package.

Sources: package.json

The dependency surface is small for normal users. The package lists standardwebhooks and json-schema-to-ts as dependencies, while zod is an optional peer dependency that supports helper workflows when users choose Zod-based schemas. If you only send basic Messages requests, you can install the SDK without adding Zod yourself. If you plan to use Zod helpers for typed schemas or structured helper flows, add a compatible Zod version from the peer range so your package manager can satisfy that optional integration cleanly.

Sources: package.json

Build configuration reinforces the published package contract. The build config extends the base TypeScript configuration, includes the distribution source tree, emits JavaScript and declarations into the distribution directory, and keeps declaration maps and source maps enabled. The Deno configuration includes its own distribution directory, targets ES2020 plus DOM library types, and performs checking without emitting files. For consumers, these files are not setup steps, but they explain why the installed package provides typed entrypoints for multiple runtime styles.

Sources: tsconfig.build.json, tsconfig.deno.json

Practical Setup Checklist

A practical new-project flow is straightforward. First, install the package with your package manager. Second, set the Anthropic API key in the environment used by your server process. Third, add a small startup or smoke-test request using the Messages API example from the README. Fourth, run that code in one of the supported runtimes rather than a browser, React Native app, or jsdom test environment. Finally, commit the dependency and keep secrets in deployment configuration rather than source control.

Sources: README.md

Use the related pages when you are ready to go deeper. Read the quickstart page for the first complete Messages request, the authentication page for client configuration and credential behavior, the runtime support page for environment-specific detail, and the Messages API page for request and response modeling. If your deployment target is a managed provider rather than the direct Anthropic API, use the provider-specific SDK pages instead of treating this installation page as universal guidance for every package in the repository.

Ask a question...