Beyond Python and TypeScript: The Other Official Claude SDKs
Most Claude tutorials assume you are writing Python or TypeScript.
Anthropic's SDK lineup is wider than that.
Beyond Python and TypeScript, Anthropic maintains official SDKs for Go, Java, C#, PHP, and Ruby.
Each one gives you the same access to Claude that the Python and TypeScript SDKs do, just wrapped in the conventions of its own language.
This page is the on-ramp for that wider set: what these SDKs actually are, how they relate to each other, and how to decide which one to reach for.
Summary
- Core Idea: Go, Java, C#, PHP, and Ruby each have an official, Anthropic-maintained SDK that wraps the same Messages API used by the Python and TypeScript SDKs.
- Why It Matters: Most production backends are not written in Python or TypeScript. A Java monolith, a Go microservice, a Rails app, or a PHP web stack can call Claude natively instead of shelling out to a Python sidecar or hand-rolling HTTP calls.
- Key Concepts: Messages API, the single wire protocol every SDK targets. Typed client, the language-specific wrapper around that protocol. Idiomatic conventions, the language-specific shape of requests, streaming, and tool_use. OpenAI compatibility layer, a separate shortcut covered elsewhere in this section.
- When to Use: Reach for one of these SDKs when your service is already written in Go, Java, C#, PHP, or Ruby and you want typed, maintained access to Claude without a cross-language hop.
- Limitations / Trade-offs: These SDKs generally receive new API surface area slightly behind Python and TypeScript, and community examples are sparser, so expect to read source or the API reference more often.
- Related Topics: Messages API fundamentals, tool use and function calling, streaming responses, the OpenAI compatibility layer.
Foundations
Every official Claude SDK, regardless of language, is a client library over the same HTTP API: the Messages API.
That means the request shape (a model, a messages array, optional system, max_tokens, tools, and so on) and the response shape (a content array of blocks, a stop_reason, token usage) are identical no matter which SDK sends the request.
What differs is how each language's SDK lets you build that request and consume that response.
A useful analogy: think of the Messages API as a single restaurant kitchen, and each SDK as a different style of menu written for a different language of diner.
The dishes coming out of the kitchen are the same; the menu you read to order them looks native to your language.
anthropic-sdk-go is the official Go SDK.
It gives you typed request and response structs, a streaming iterator, and structured support for tool_use, all built with Go's conventions: explicit error returns, functional options for client configuration, and no exceptions.
The Java and C# SDKs lean on their platforms' object models: builder patterns and typed request objects in Java, strongly typed request/response classes and async/await in C#.
The PHP and Ruby SDKs favor their own idioms too: PHP typically expresses tool schemas and options as associative arrays, while Ruby expresses the same information as hashes and takes advantage of Ruby's flexible method signatures.
Authentication is consistent across all of them: every SDK's client constructor accepts an API key, conventionally read from an ANTHROPIC_API_KEY environment variable, and attaches it to outgoing requests the same way the Python and TypeScript SDKs do.
client := anthropic.NewClient(
option.WithAPIKey(os.Getenv("ANTHROPIC_API_KEY")),
)That one call is the shape of "hello world" in every one of these SDKs: construct a client from an API key, then call the Messages endpoint through it.
Mechanics & Interactions
Because all seven official SDKs sit on top of the same Messages API, a request built in Go and a request built in Ruby produce functionally identical JSON on the wire.
This has a practical consequence: documentation, prompt design, and model behavior notes written for the Python or TypeScript SDK still apply when you're working in Go, Java, C#, PHP, or Ruby.
Only the code that builds the request looks different.
Where the SDKs genuinely diverge is in three areas covered by other articles in this section: tool_use definition syntax, streaming consumption, and error/exception types.
Tool_use is the sharpest divergence.
Go, Java, and C# lean on structs and typed schemas to describe a tool's input; PHP and Ruby lean on associative arrays and hashes, since neither language has first-class static typing for this the way Go, Java, and C# do.
The wire format Claude receives, an input_schema as JSON Schema, is identical either way.
Streaming is the second divergence.
Java and C# each expose their platform's native streaming primitive: an iterator you loop over in Java, an async enumerable or callback-driven stream in C#.
Go's SDK exposes a streaming iterator in the same spirit as Java's.
PHP and Ruby streaming tends to follow a callback or generator pattern depending on the SDK version.
In every case, what's being streamed is the same sequence of server-sent events: message_start, content_block_delta, message_delta, message_stop, and so on.
Error handling is the third divergence, and the most language-specific.
Go returns errors as values, following Go convention.
Java and C# throw typed exceptions that map to HTTP status categories (authentication, rate limit, overloaded, and so on).
PHP and Ruby raise exceptions or errors that follow each language's own class hierarchy conventions.
None of this changes what error occurred on Anthropic's side; it only changes how your calling code notices and handles it.
Advanced Considerations & Applications
Choosing an SDK is really choosing a deployment target, not a personal language preference.
If your team runs a polyglot backend, for example a Go API gateway, a Java service mesh, and a Ruby admin panel, it is entirely normal to use three different official Claude SDKs across that stack, all talking to the same Messages API with the same model names and the same prompts.
There is no cross-SDK compatibility tax for doing this: nothing about the Messages API cares which SDK sent the request.
A separate, faster-but-narrower path exists for teams that already have OpenAI SDK code: the OpenAI compatibility layer lets you point that existing code at Claude by swapping the base URL and model name, without adopting a native Anthropic SDK at all.
That path trades completeness for speed, since not every OpenAI parameter maps cleanly onto the Messages API, and it is covered in depth elsewhere in this section.
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
| Native Go/Java/C#/PHP/Ruby SDK | Full Messages API surface, typed, idiomatic error handling | One more dependency per language in a polyglot stack | Production services already written in that language |
| OpenAI compatibility layer | Fast to adopt, minimal code change | Some parameters do not map cleanly; not the full Messages API surface | Quick migration or side-by-side testing, not the long-term production path |
| Manual HTTP calls | No dependency at all | You reimplement typing, retries, and streaming parsing yourself | Environments where no official SDK exists for the language |
As Anthropic ships new capabilities, such as new tool_use features or new content block types, expect the Python and TypeScript SDKs to receive them first, with Go, Java, C#, PHP, and Ruby following.
For most application code this lag is invisible, since the core Messages API surface (send messages, receive content, use tools, stream) has been stable across all seven SDKs for a long time.
Common Misconceptions
- "The Go/Java/C#/PHP/Ruby SDKs are unofficial community wrappers." They are not. Anthropic maintains all seven SDKs directly, the same way it maintains the Python and TypeScript ones.
- "Switching SDKs changes what the model can do." It doesn't. The model, its capabilities, and its behavior are determined by the Messages API and the model you select, not by which SDK sent the request.
- "You need the OpenAI compatibility layer to use Claude from Go, Java, C#, PHP, or Ruby." You don't. Each of those languages has its own native, typed Anthropic SDK; the compatibility layer is a separate, narrower shortcut for teams migrating existing OpenAI SDK code.
- "Tool_use works differently depending on the SDK." The tool_use protocol itself, what Claude sends and expects back, is identical everywhere. Only the syntax for defining and reading it differs by language.
- "These SDKs are behind on features in a way that matters for typical apps." For the core surface, sending messages, using tools, streaming, all seven SDKs are functionally complete. Lag mostly affects brand-new, cutting-edge capabilities.
FAQs
Which languages have an official Claude SDK besides Python and TypeScript?
- Go (
anthropic-sdk-go) - Java
- C#
- PHP
- Ruby
All five are maintained directly by Anthropic.
Do these SDKs all talk to the same API?
Yes. Every official SDK, in any of the seven languages, is a client for the same Messages API. The request and response JSON shape is identical regardless of which SDK sent it.
Is one of these SDKs "more official" than the others?
No. Python, TypeScript, Go, Java, C#, PHP, and Ruby are all first-party, Anthropic-maintained SDKs. None is a community fork or unofficial wrapper.
How do I decide which SDK to use?
- Match the SDK to the language your service already runs, not to personal preference.
- If you're polyglot, it's normal to use a different SDK per service.
- If you already have OpenAI SDK code and just need a fast migration or test, consider the OpenAI compatibility layer instead of adopting a new native SDK immediately.
Does tool_use work the same way across all five SDKs?
The protocol is the same everywhere. The syntax differs: Go, Java, and C# use typed structs for tool schemas, while PHP and Ruby use associative arrays and hashes respectively. What Claude receives on the wire is identical either way.
Do Go, Java, C#, PHP, and Ruby support streaming?
Yes, all five support streaming responses. Java and C# use their platform's native streaming iterator or async callback mechanism; Go exposes a similar streaming iterator. The underlying server-sent events are the same across every SDK.
Are these SDKs slower to get new features than Python and TypeScript?
Sometimes. New, cutting-edge API capabilities tend to land in Python and TypeScript first, with the other SDKs following. The stable core (messages, tools, streaming) has long been consistent across all seven.
What is the OpenAI compatibility layer, and is it one of these SDKs?
No, it's a different thing. It's a compatibility endpoint that lets you point existing OpenAI SDK code (in any language OpenAI supports) at Claude by changing the base URL and model name, rather than adopting a native Anthropic SDK. It covers a narrower parameter surface than the native SDKs.
Can I mix SDKs across services in the same company or product?
Yes. Since every SDK talks to the same Messages API, a Go service and a Ruby service can both call Claude, with the same model names and prompt design, without any compatibility concerns between them.
Do authentication conventions differ between SDKs?
No. Every SDK's client constructor accepts an API key, conventionally sourced from an ANTHROPIC_API_KEY environment variable, and attaches it to requests the same way.
Where should I go next to actually write code in one of these languages?
Start with the Basics page for a first call in each language, then the Go-specific deep dive if you're working in Go, and the tool use comparison page if you need tool_use specifically.
Related
- Other Official SDKs Basics - send a first Messages API call in each of the five languages
- Calling Claude from Go with the Official SDK - a deeper, Go-specific walkthrough of typed requests, streaming, and tool_use
- Idiomatic Tool Use Across Go, Java, C#, PHP, and Ruby - compare tool definition syntax across all five SDKs
- Migrating an OpenAI SDK Codebase to Claude - the OpenAI compatibility layer shortcut, and when to graduate to a native SDK
- Tool Use Basics - the underlying tool_use protocol these SDKs all wrap
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the current official SDKs for Go, Java, C#, PHP, and Ruby. Model names, SDK versions, and pricing move quickly - verify current specifics at platform.claude.com/docs before relying on them.