SEC 02 / PACKAGES

SDK & package map

There is no single “ElevenLabs SDK” — instead there are eight official packages, one per environment, each owning a different slice of the platform.

The package distinction that bites people

The maintained Node server package is:

@elevenlabs/elevenlabs-js

The browser conversational package is:

@elevenlabs/client

They are not interchangeable. @elevenlabs/elevenlabs-js is the broad REST client meant to run on a trusted server; @elevenlabs/client owns the microphone, WebRTC, conversation, and client-side real-time behaviour of a browser tab. Reaching for the Node package inside a browser bundle — or expecting the browser package to cover general REST operations — is the mistake this distinction exists to prevent. The official Node repository explicitly directs browser and React applications to the client and React packages instead.

What the core API actually covers

The public API surface is much broader than text-to-speech:

That breadth means the core SDK reads closer to an automatically generated client for the full ElevenLabs platform than a focused “TTS helper.” Expect to find resources for phone numbers, knowledge bases, and batch calling alongside the audio endpoints you came for.

Typical core-client operations look like this:

client.text_to_speech.convert(...)
client.text_to_speech.stream(...)
client.voices.search(...)
client.voices.ivc.create(...)

Python exposes both ElevenLabs and AsyncElevenLabs entry points; the Node package uses a single ElevenLabsClient.

Generated-client implications

The core packages are largely generated from the API specification. That gives extensive typed coverage and rapid access to new endpoints, but it carries real consequences for how you build on top of them:

• Generated source is not a safe place for local customizations.
• Regeneration can rearrange types and method internals.
• Application code should wrap the SDK behind an internal adapter.
• Version upgrades should be tested rather than accepted automatically.
• Response parsing should tolerate new fields.

ElevenLabs’ compatibility policy treats adding response properties as a non-breaking change — clients are expected to ignore fields they don’t understand. Removing fields or changing their types incompatibly is treated as breaking. Write your response parsing accordingly, and don’t hand-edit generated files; the Node repository warns that direct edits to generated areas may be silently overwritten on the next regeneration.

References

• Official libraries list
• Breaking changes policy
• elevenlabs-js on GitHub
• elevenlabs-python on GitHub
• elevenlabs on PyPI