This repo contains the source for the ElevenLabs documentation site, the Next.js example app and the SDK generation.

The autogenerated content (docs and SDK) all live inside the fern folder.

We welcome contributions to the ElevenLabs documentation, but ask that you first read through the style guide before submitting pull requests.

The Fern CLI is what builds the documentation.

Install pnpm

npm install -g pnpm

Install the dependencies

pnpm install

Run the following command at the root of the folder

pnpm run dev

Run the following command to lint/format the project

pnpm run fmt

The documentation includes tested code snippets that demonstrate how to use ElevenLabs APIs and SDKs.

1. Create Code Examples:

   • Write language-specific examples in examples/snippets/ directory
   • Organize by language: examples/snippets/python/ and examples/snippets/node/
   • Use consistent naming across languages (e.g., quickstart_tts.py and quickstart_tts.mts)

2. Test Snippets:

   • Run pnpm run snippets:test to verify all snippets have valid syntax
   • Run pnpm run snippets:typecheck to check TypeScript types

3. Generate Documentation Snippets:

   • Run pnpm run snippets:generate to create MDX files with code blocks
   • The script combines examples from different languages into CodeBlocks components
   • Generated files are placed in fern/snippets/generated/

4. Use in Documentation:

   • Import the generated MDX files into documentation using the <Markdown> component:

   <Markdown src="/snippets/generated/quickstart_tts.mdx" />

This workflow ensures that all code examples in the documentation have valid syntax and stay up-to-date.

When you run pnpm run openapi:update to update the OpenAPI spec, new endpoints may appear at the bottom of the API reference instead of being organized into the appropriate sections. This is because the documentation organization is controlled by the fern/docs.yml file.

The fern/docs.yml file controls how API endpoints are organized and displayed in the documentation. It has two main sections:

1. Product Guides (docs tab): Contains user-facing documentation, tutorials, and guides
2. API Reference (api-reference tab): Contains the actual API endpoints organized from the OpenAPI spec

When new API endpoints are added to the OpenAPI spec, you need to manually organize them in docs.yml. There are two ways to reference endpoints:

1. Endpoint Groups: Reference entire groups of related endpoints using their OpenAPI tag name:

   contents:
     - workspace
     - textToSpeech
     - speechToText

2. Individual Endpoints: Reference specific endpoints with custom organization:

   contents:
     - section: Service Accounts
       contents:
         - endpoint: GET /v1/workspace/service-accounts
           title: Get Workspace Service Accounts
         - endpoint: POST /v1/workspace/service-accounts
           title: Create Service Account API Key
         - endpoint: DELETE /v1/workspace/service-accounts/{api_key_id}
           title: Delete Service Account API Key

To add new Service Accounts endpoints under the Administration section:

1. Locate the ADMINISTRATION section in the api-reference layout (around line 1027 in docs.yml)
2. Add the endpoints to the appropriate subsection:

   - section: ADMINISTRATION
     skip-slug: true
     contents:
       - history
       - models
       - section: Studio
         # ... existing studio endpoints
       - section: Service Accounts # Add this new section
         contents:
           - endpoint: GET /v1/workspace/service-accounts
             title: Get Workspace Service Accounts
           - endpoint: POST /v1/workspace/service-accounts
             title: Create Service Account API Key
           # ... other service account endpoints
       - pronunciationDictionaries
       # ... rest of administration endpoints

• Group Related Endpoints: Organize endpoints into logical sections (e.g., Service Accounts, Webhooks, Studio)
• Use Descriptive Titles: Provide clear, action-oriented titles for endpoints
• Maintain Hierarchy: Place new sections in logical positions within existing structures
• Test Locally: Run pnpm run dev to preview changes before committing

This organization ensures that new API endpoints appear in the correct sections of the documentation rather than being automatically placed at the bottom of the list.

We support the following SDKs which can be used to interact with the ElevenLabs platform:

• Python
• Typescript

While this public repo contains the source for generating ElevenLabs SDKs, only ElevenLabs employees can trigger a regeneration.

The SDK generation is based on two specs and a configuration file:

• OpenAPI spec
• AsyncAPI spec
• Generators config

1. Deploy the backend with the updated OpenAPI spec
2. Update openapi.json in this repo with the new OpenAPI spec (pnpm run openapi:latest)
3. (Optional but recommended) Run fern check to validate the API and fern generate --group python-sdk --preview to create the generated intermediate step locally
4. (Optional) Test the changes locally by running fern generate --group python-sdk --preview and inspecting the generated folder
5. Add in appropriate overrides to the openapi-overrides.yml doc, and repeat steps 3 and 4 until it's correct
6. Trigger the Python and Typescript Github Actions. To do this, go to the Actions tab and click Release TypeScript SDK or Release Python SDK. Enter in the appropriate version number e.g. 1.1.1 (bumped from what's currently released). This will create PRs into the elevenlabs-python or elevenlabs-js repos. Note: Only ElevenLabs employees can trigger these actions.
7. Review and merge the PRs into the elevenlabs-python or elevenlabs-js repos.
8. Create a release tag on both the Python and Typescript repos to release them.

To validate your API, run:

pnpm install
pnpm run fern:check

To view the changes locally run

fern generate --group python-sdk --preview
# `fern write-definition` shows you the intermediate step