Generated SDKs – Overview

When API producer teams push schemas to the Buf Schema Registry (BSR), it automatically generates SDKs for multiple languages that package up code generated from the Protobuf files and the BSR's remote plugins. Client teams can consume these SDKs using the language and package manager of their choice, just like any other dependency. This greatly simplifies workflows for your teams:

Natively integrate generated SDKs across backend, frontend, and mobile clients
Consume SDKs without worrying about your Protobuf environment, compiler, or plugins
Iterate on staged API changes using pre-release SDKs before merging schemas to the default label
Take advantage of the BSR's automatic organization-wide SDK caching
Automatically pick up version changes using Dependabot or similar tools
View API reference documentation from the SDK directly from the BSR

Improved dependency management

Generated SDKs give your package manager all the information necessary to manage Buf module dependencies, plugins, and runtime dependencies for you:

Buf module dependencies become package dependencies. You don't need to manually track them.
Many plugins generate code that requires code generated by another plugin. For example, a generated gRPC client typically requires generated Protobuf messages and other types. The generated SDK for gRPC has a package dependency for the Protobuf types, so they're automatically installed.
Most plugins generate code that requires a runtime library. For example, a generated gRPC client requires a gRPC networking library that's published in the ecosystem's main package registry (such as the npm public registry). These runtime dependencies are also added as package dependencies to generated SDKs, so they're automatically installed.

As a result, you only need to install a single generated SDK to use the schema.

Developing against pre-release code

In addition to simpler dependency management, generated SDKs also make iterating on Protobuf APIs easier. All labels in the BSR produce SDKs, allowing consumer teams to work with pre-release client code before pushing their APIs to the default label. Consumers can use the latest version of a generated SDK (the default) or pin it to a specific commit or label instead.

Go to the tutorial to learn how to install generated SDKs from the BSR, or the guides linked below for manual installation instructions and specific versioning syntax.

Configuration limitations

Generated SDKs have no configuration options, so for Free and Teams plans, you can't configure plugin options for them. For example, using them requires that all of the module's imports also use generated SDKs, so if you need a different import path, you need to generate your own code.

To customize plugin options for the generated code, you can use the Buf CLI to generate the files yourself, and provide whatever configuration you want:

Configure using custom plugins

This feature is only available on the Pro and Enterprise plans.

If you're on a private BSR instance, you can use the custom plugin feature to fork and change the configuration of the BSR's curated plugins. You can then upload it to the BSR and use it instead of the curated one (you may want to adjust your recommended sdks to reflect this). Doing so means that you take on the burden of troubleshooting and maintenance, but for some organizations this method is a reasonable tradeoff.