Keeping SDKs in sync with your API can quickly become a bottleneck - especially when manual updates delay your release cycles. Every API change that requires a corresponding SDK update adds friction and risk. By integrating SDK generation into your CI/CD pipeline, you can automate updates, ensure consistency, and streamline the release process.

This post shows how to set up a CI/CD workflow for SDK projects using liblab. You'll see practical examples with GitHub Actions and learn how to automatically generate and publish SDKs from OpenAPI specs.

Why CI/CD Matters for SDK Projects

Maintaining SDKs manually is time-consuming and error-prone. Every time an API changes, you need to update the SDK, validate it, and publish a new version. Doing this manually across multiple languages is costly and hard to scale.

CI/CD pipelines automate this process. When integrated with tools like liblab, they can:

• Automatically regenerate SDKs from updated API via OpenAPI specs
• Publish new versions to package managers

This ensures your SDKs are always current and consistent, enabling faster and more reliable developer experiences.

Project Structure and Workflow Overview

Before diving into the CI/CD configuration, let's take a look at how the components are organized and how they interact.

This setup involves two directories:

• ci-cd-integration - A monorepo that contains the API, the SDK generation config, and a GitHub workflow that triggers SDK generation based on API changes.

  • /api contains the API code and serves the OpenAPI spec on the /openapi-json route. In this example, the API is deployed publicly at https://ci-cd-integration.onrender.com/ for easier access to the spec from the GitHub Action. Note that we're using Render's free tier, which can cause the loading to take a bit longer due to the cold start.
  • /sdk-control contains:
    • liblab.config.json - The configuration file that defines SDK generation.
    • api.json - The OpenAPI spec used in the last SDK build (used for diffing, this file will be automatically updated before we go on to build the SDK in CI/CD).

  These two folders can be in separate repositories - it's a matter of personal or team preference. In this example, for simplicity, we're including them in the same repo.

  We also have example SDKs of the results of this process if you're interested in seeing what they look like once the CI/CD pipeline is built and the SDKs are generated:

• hello-world-sdk-python - Contains the generated Python SDK.

• hello-world-sdk-typescript - Contains the generated Typescript SDK.

Workflow Overview

The goal of this workflow is to automatically regenerate SDKs and publish a PR to the SDK repository whenever there's a change in the API.

Here's a brief overview of how it works before we dive into the details:

1. Deploy the API

   When a commit is pushed to main, the deploy-and-sync-sdk.yml GitHub Action deploys the API (in this example, to Render) and then proceeds to sync the SDK.

2. Detect API changes

   Once deployed, the action fetches the latest OpenAPI spec from the live API and compares it with the version stored in sdk-control/api.json (used for the previous SDK build). If there are no differences, the action exits.

3. Commit and push the new spec file

   If changes are detected, the action commits and pushes the updated api.json.

4. Update the SDK version

   In this setup, the minor version is incremented in liblab.config.json.

5. Build the SDK

   The build is triggered using the liblab build command, which takes the updated OpenAPI spec and config file and generates the new SDKs for Python and Typescript.

6. Commit and push the updated config file

7. Create a PR on SDK repositories

   Pull requests are created using the liblab pr command.

This setup ensures your SDK always reflects the current state of your API - without manual steps.

Repository Secrets

To enable CI/CD automation, we'll need to add several secrets to your GitHub repository:

• LIBLAB_GITHUB_TOKEN: A fine-grained GitHub token used by liblab to create pull requests to SDK repositories.
• LIBLAB_TOKEN: A token used to authenticate your CI/CD pipeline with the liblab service.
• RENDER_API_KEY, RENDER_DEPLOY_HOOK_URL, RENDER_SERVICE_ID: Used to trigger redeploys on Render after API changes.

note

You can follow the official liblab guide to create both the GitHub and liblab tokens.

Step-by-Step: From API Change to Updated SDK

Let's walk through a full cycle: from updating the API to seeing the new SDK generated and proposed as a pull request.

1. Make a Change to Your API and Push to main

   In this example, we add support for Japanese to our "Hello World" API. Once the change is committed and pushed to the main branch, the CI/CD pipeline kicks off automatically.

   note

   For the sake of simplicity, we're pushing the change directly to the main branch. In a real-world setup, you'd typically open a pull request, review it, and merge it to trigger the workflow.

2. Deploy New API Version

   The deploy-and-sync-sdk.yml workflow runs on every push to main. In this case I've deployed the API to Render but you can use any hosting service.

   

3. Sync SDK With API Changes

   After deployment, the workflow fetches the live OpenAPI spec and compares it with the version stored in sdk-control/api.json.

   If a change is detected:

   • api.json is updated and committed
   • The version is bumped in liblab.config.json
   • A new SDK is built using liblab build
   • Pull requests are created in the SDK repositories with the fresh SDKs. One PR in each repository for each programming language.

   

4. Review the SDK Pull Request

   The hello-world-sdk-python and hello-world-sdk-typescript repositories receive automatic pull requests with the updated SDK files. We can now review the changes before merging.

5. Merge the PR 🎉

   Once the pull request is approved and merged, the new SDK version is ready to be published.

   The entire loop - from API change to up-to-date SDK - runs without any manual steps.

Next Steps

With this setup it's simple to automate the most critical part of your SDK lifecycle - keeping it in sync with your API. From here, you can take your CI/CD pipeline even further:

• Publish to package managers - Automate releases to npm, PyPI, Maven, NuGet or other ecosystems so developers can consume updates without delays.
• Add automated testing - Validate that the generated SDK behaves correctly before it gets merged.
• Integrate Changelog generation - Include meaningful release notes for each SDK update.
• Set up notifications - Alert your team or community when new SDK versions are available.

info

This blog post doesn't cover SDK publishing, but this tutorial shows how to set up a full CI/CD pipeline, including publishing to package managers.

Conclusion

Automating SDK generation with CI/CD not only saves time, it also improves reliability and developer experience. By integrating liblab into your pipeline, you ensure your SDKs stay up to date with every API change - without any manual work. Set it up once, and let your workflow handle the rest.