7 SDK Generator Tools for APIs in 2025

As developers, we constantly seek ways to streamline our workflows and improve efficiency. One tool that’s gained traction in recent years is the SDK generator. These tools automate the creation of software development kits (SDKs) for APIs, simplifying the process of integrating external services into applications. In this post, we’ll dive into the world of SDK generator tools, examining their features, benefits, and how they can save valuable time for developers working with APIs.

These tools can help you:

1. Grow the number of developers building with your API.

2. Shorten the time to go live aka “time to 200”.

3. Reduce the number of support requests from developers.

What’s on our agenda?

• What is an SDK Generator tool?
• Why would you need one?
• How can we test them?
• My final verdict
• Let’s analyze the available options

APIMatic

OpenAPI-Generator

Fern

Stainless

Speakeasy

Kiota

AutoRest

• Conclusion

What is an SDK Generator tool

When I think about software development, problem-solving and creating something new excites me. When designing scalable systems, optimizing performance, and crafting elegant solutions.

But in reality, when connecting two software systems, the work can feel more repetitive than rewarding. Especially when working with HTTP APIs and sending JSON over the wire. This is where Software Development Kits (SDKs), the unsung heroes of modern web development, come in. SDKs are pre-written code, instructions, and reference documentation that help a dev build an integration faster and more reliably. This leads to a faster time to go live and less ongoing maintenance.

When creating an SDK, there are three options:

1. Write it manually. (Customizable, high quality, high cost, expensive to maintain)

2. Use an open-source generator. (No cost, lower quality, requires an engineer to augment with custom scripts, no support)

3. Use an SDK vendor. (Highest quality, can be offered instantly, Slack-based support, requires paid subscription)

Why It Matters

• Efficiency: Faster development with less boilerplate.
• Consistency: Standardized, easy-to-maintain SDKs.
• Empowerment: Developers can focus on building features, not handling low-level integrations.

SDK generators are a smarter way to streamline development, improve scalability, and boost developer satisfaction.

Why would you need one

The need for an SDK generator tool arises when efficiency, consistency, and scalability become priorities. If your team manages APIs or services that require integration across multiple platforms or programming languages, creating SDKs manually can be time-consuming and prone to errors. An SDK generator eliminates this bottleneck by providing:

1. Time Savings: Automating SDK creation frees up developers to focus on more critical tasks, such as improving core functionality or enhancing user experience.

2. Consistency: Generated SDKs follow the same patterns and conventions, reducing the likelihood of inconsistencies across different language implementations.

3. Scalability: As your platform evolves or new APIs are introduced, updating SDKs becomes a straightforward process, ensuring your integrations remain up-to-date without significant overhead.

4. Developer Enablement: By offering prebuilt SDKs, you make it easier for external developers or clients to integrate with your platform, fostering a stronger and more productive developer community.

An SDK generator tool is about efficiency, scalability, and developer happiness. It’s not just a shortcut; it’s a smarter way to approach software development. So, if you’re managing APIs or developing platforms that others need to integrate with, it’s worth exploring how SDK generators can elevate your development game.

How can we test them

Not too long ago, I had the opportunity to write a blog post for my friends at Zuplo titled How to Build an API with Ruby and Sinatra. In that post, I walked through the process of building a straightforward yet functional API using Ruby and the lightweight Sinatra framework. The goal was to show just how accessible API development can be, even for those who might be new to it.

What made the process even more exciting was incorporating ChatGPT into the workflow. After building the API, I used ChatGPT to generate a complete OpenAPI Specification — a task that would have otherwise required a fair amount of manual effort and attention to detail. With just a bit of guidance, ChatGPT produced a spec that was not only accurate but ready to use, saving me valuable time.

But the story doesn’t end there. That very OpenAPI Specification is now pulling double duty: it’s becoming the foundation for something even more practical. We’ll use it to test and compare a range of SDK generator tools to see how they perform and what they bring to the table. This process will shine a light on just how much these tools can simplify development by transforming API specs into ready-to-use SDKs in various programming languages. So stay tuned as we put these tools through their paces and explore the possibilities they offer for making integration faster and easier than ever.

My Final Verdict

After trying all these tools, two stand out: Fern and APIMatic. Both deliver an excellent user experience, great SDK production, and clear documentation, despite having completely different approaches. Since I value both the SDKs and documentation equally, I’d choose Fern for its SDKs because the code quality is clean, well-structured, and feels the most hand-written — it’s idiomatic and typesafe by default. Feel free to reach out with any questions or comments! I plan to update this article in 2026.

Let analyze the available options

APIMatic

Maximize API Adoption by Speaking Your Developers Language!

• Multi-Language SDK Generation → It supports JavaScript, Python, Ruby, PHP, C#, Java, TypeScript, Objective-C, Go, and Dart. Support for Swift is coming soon.

• Analytics and Insights → Offers usage analytics for SDKs and API documentation, giving insights into how developers are using your APIs.

• API Mocking → Provides mock servers for testing and simulating API responses without hitting live endpoints.

• Developer Experience → Provides a developer portal for easy access to SDKs, API documentation, and other resources.

• API Transformations → Converts API descriptions between multiple formats (OpenAPI (Swagger), RAML, API Blueprint, Postman Collections, HAR (HTTP Archive), and more).

APIMatic has an interesting requirement for registration: you need a business email address to sign up. However, I reached out to support, and they kindly provided me with a test user, so we’ll be able to discuss it.

When we log into APIMatic, we’re greeted with two options for creating our SDK: either by describing the API manually or by importing an OpenAPI Specification. For simplicity and efficiency, we’re going to go with the second option — importing an OpenAPI Spec. This allows us to leverage an existing API definition to streamline the SDK generation process. Let’s dive in and get started!

Importing our OpenAPI Spec

Next, we need to provide APIMatic with our OpenAPI Specification. There are two ways to do this:

1. Upload the OpenAPI Spec directly from our local system.

2. Provide the URL where the file is hosted.

For this guide, we’ll go with the first option and upload the OpenAPI Spec directly. This straightforward approach ensures that APIMatic has everything it needs to generate the SDK efficiently. Let’s proceed with the upload and move on to the next step!

OpenAPI Spec selected

Once the OpenAPI Spec is uploaded, APIMatic provides a helpful logging summary. This summary gives you a clear overview of the import process, highlighting any errors or warnings that may need our attention.

It’s a great way to ensure that our API definition is in good shape before moving forward. If there are issues, we can address them right away, saving time and avoiding problems down the line. With everything in order, we’re ready to move on to the SDK generation!

Errors, Warning and Messages on our OpenAPI Spec

Once everything is processed, APIMatic generates two key resources for us:

1. The API Portal: This is the comprehensive documentation for your API, neatly organized and ready to be explored.

2. The SDK: The actual code for our SDK, which you can choose to either download for local use or publish, making it available for others to access and download.

For this guide, we’re going to take a closer look at the API Portal to review the documentation and ensure everything looks good. After that, we’ll download the SDK so we can test it locally on our machine. Let’s start by exploring the API Portal and see how the documentation turned out!

Generation of SDK and Documentation

The API Portal generated by APIMatic is impressively well-crafted. It provides a clear and organized list of all the API endpoints and models, making it easy to navigate and understand our API’s structure.

One standout feature is the ability to choose the programming language for the SDK. APIMatic generates SDKs for multiple languages, and you can simply download the one you need — this flexibility is incredibly convenient for developers working in different tech stacks.

Additionally, the portal offers options to either publish or customize it. The ability to tailor the portal to our brand or specific requirements adds significant value, especially if you plan to share it with external developers or stakeholders.

Another thoughtful addition is the step-by-step tutorial embedded in the portal. This guide helps users get up to speed quickly, making the onboarding experience smoother and more intuitive. Overall, it’s a great combination of functionality and user experience!

Generated API Portal (Documentation)

When it comes to customizing the API Portal, APIMatic offers a high level of flexibility — we can change just about everything. From the design and layout to the branding elements like logos, colors, and fonts, you have full control to tailor the portal to match our organization’s style and requirements.

Personalization of API Portal

Let’s proceed by downloading the Python SDK to see how it performs. Once downloaded, we’ll take a closer look at the generated code to evaluate its structure, functionality, and ease of use. After that, we can run some tests to explore how it behaves in a real-world scenario. Let’s dive in and put the SDK to the test!

Selection an SDK Language

We selected Python as the target language and downloaded the SDK, which comes packaged neatly in a .zip file. Once the download is complete, we can extract the files to review the generated code and folder structure. From there, we’ll set up our environment and start experimenting with the SDK to see how well it integrates and performs.

SDK Generated in a .zip file

Once the SDK is unzipped and placed into our working directory, the next step is to set it up locally. This involves installing the dependencies, building the package, and then installing it. Open the terminal and run the following commands:

Install the required dependencies:

pip3 install -r requirements.txt

Build the SDK package using Poetry:

poetry build

Install the generated package locally:

pip3 install dist/dunequotesapi-1.0.0-py3-none-any.whl

With the SDK installed, we’re ready to create a test script to put it through its paces. Here’s an example script you can use to test the functionality of the generated SDK:

from dunequotesapi.dunequotesapi_client import DunequotesapiClient

client = DunequotesapiClient()

quotes = client.client.get_quotes()

for quote in quotes:
    print(f'#{quote.character} ==> #{quote.quote}')

OpenAPI Generator

Generate clients, servers, and documentation from OpenAPI 2.0/3.x documents

• Multi-Language SDK Generation → Supports over 50 programming languages for SDK and client library generation, including Java, TypeScript, Python, Ruby, PHP, C#, Go, Swift, Kotlin, Dart, JavaScript, and more.

• Wide Compatibility → Supports OpenAPI Specification versions 2.0, 3.0, and 3.1, making it compatible with modern API designs.

• Community and Open Source → Fully open-source with a large, active community.

• Plugins and Ecosystem Support → Integrates well with tools like Swagger Editor, Postman, and API Gateway platforms.

• Easy Integration with CI/CD → Easily integrates into CI/CD pipelines to ensure SDKs and server stubs are automatically updated with API changes.

First things first, we need to get the OpenAPI-Generator CLI installed. While there are many ways to install it, I prefer using Homebrew for its simplicity. Run the following command to get started:

brew install openapi-generator

With the CLI installed, the next step is to generate the SDK. In this case, we’ll target Ruby. To do so, use the following command:

openapi-generator generate -i DuneQuotesSpec.yaml -g ruby -o /tmp/test/

And just like that, our Ruby SDK is up and running! However, I have to admit that testing the generated SDK wasn’t as smooth as I’d hoped. Browsing through the generated folders and files felt a bit cumbersome. Finding exactly what I needed took more effort than expected, and the naming conventions didn’t quite align with my expectations. This made the process of exploring and testing the SDK more time-consuming than it should have been:

require 'openapi_client'

test = OpenapiClient::DefaultApi.new()
quotes = test.api_v1_quotes_get()

quotes.each{ |quote|
 puts "#{quote.character} ==> #{quote.quote}"
}

OpenAPI Generator — Running the Ruby SDK

You might be wondering how to generate documentation for our API. Luckily, OpenAPI-Generator makes this an incredibly straightforward task. All you need to do is run the following command:

openapi-generator generate -i DuneQuotesSpec.yaml -g html -o docs

This will generate a set of clean, HTML-based documentation for our API and save it to the docs folder. With just one command, you’ll have a professional-looking API reference that’s ready to share with our team or users. Simple and effective!

Generated documentation for the SDK

Fern

Instant SDKs and API Docs

• Multi-Language Support → It supports TypeScript, Python, Java, Go, Ruby, PHP, and C#. Support for Swift, Rust, Terraform, and CLI is coming soon.

• Seamless API Documentation → Automatically generates developer-friendly API documentation that integrates with your SDKs.

• Unified Tooling → Fern combines SDK generation and API documentation into a single platform.

• Developer-Focused Experience → Provides a modern, easy-to-use CLI and toolchain that simplifies SDK creation and maintenance.

• Focus on CI/CD Integration → Easily integrates into CI/CD pipelines for automated SDK updates when API specifications change.

First things first, we need to get the Fern CLI installed. To do this, run the following command:

npm install -g fern-api

Once installed, the next step is to initialize the Fern folder. Using our OpenAPI specification file, run:

fern init --openapi duneQuotesSpec.yaml

This will set up a working environment for Fern. Now, it’s time to add the language we want to target. In this case, we’ll be generating an SDK for Ruby. To add Ruby as the target language, execute:

fern add fern-ruby-sdk --group SDK

With everything configured, we’re ready to generate the SDK, which was idiomatic, typesafe, and overall perfectly organized and easy to read. Run the following command to kick off the generation process:

fern generate --group SDK

And that’s it! We just generated a Ruby SDK with Fern, using our OpenAPI specification as the foundation.

To put the generated SDK to the test, I created a straightforward file to ensure everything works as expected. This file serves as a basic playground to verify that the SDK functions correctly and interacts seamlessly with the API.

require 'atejada_api_client'

test = AtejadaApiClient::Client.new()
quotes =  test.get_quotes()

quotes.each{ |quote|
 puts "#{quote.character} ==> #{quote.quote}"
}

Fern — Running the Ruby SDK

But what about documentation? After all, an SDK is only as good as its documentation — developers need clear, accessible guidance to make the most of it. Thankfully, Fern makes this process just as simple. To generate documentation, we need to start by initializing the docs folder with the following command:

fern init --docs

Once the folder is set up, generating the documentation is just as straightforward. Run:

fern generate --docs

And that’s it! We now have properly generated documentation to complement our SDK, ensuring developers have all the tools they need to integrate seamlessly with our API.

Generated documentation for the Ruby SDK

Stainless

Generate best-in-class SDKs

• SDK Generation → It supports Node/TypeScript, Python, Go, Java, Kotlin, Ruby, and Terraform.

• Typed Models and Strong Validation → Generates strongly-typed models to improve reliability and usability in SDKs.

• Streamlined Updates → Automates SDK updates whenever API specifications change, ensuring the SDKs stay in sync with the API.

• Lightweight and Modern → Stainless is a lightweight, modern tool built for fast-moving teams.

• Simplified Authentication → Built-in support for various authentication methods, including OAuth2, API keys, and more.

To generate our SDK, the first step is to provide some essential information and upload our OpenAPI Specification file. This ensures that the tool has everything it needs to create a tailored SDK based on the API’s structure and endpoints. The process is straightforward, and once the details are filled in, you’re ready to kick off the generation!

Stainless sign up page

By default, once the generation process is complete, the tool provides two SDKs ready to use: one for Node.js and another for Python. This makes it easy to get started with two of the most popular programming environments right away, catering to both backend and scripting needs.

Stainless SDK overview page

That said, since we’re aiming to generate a Ruby SDK, the next step is to click on the “Add SDKs” button:

Available languages

I could opt for Go, request Java or Kotlin, but Ruby isn’t available just yet. Not a major issue, though — we can always test our solution using Python.

SDK Generated Private Repo

By heading to the GitHub-generated repo, we can find the installation instructions and testing steps, which will undoubtedly save us a significant amount of work.

from dunequotes import Dunequotes

client = Dunequotes()

quotes = client.quotes.list()

for quote in quotes:
    print(f'#{quote.character} ==> #{quote.quote}')

Stainless generated Python SDK

So, where are the docs? Unfortunately, I couldn’t find them. The GitHub repo points to https://docs.dunequotes.com/, but that path doesn’t exist. I even searched through the entire repo and came up empty-handed.

Speakeasy

The platform to Build APIs your users love

• Idiomatic SDK Generation → Generates developer-friendly SDKs in multiple programming languages, such as TypeScript, Python, Go, Java, C#, PHP [beta], Unity [beta], Ruby [alpha], and Swift [alpha]

• API Consumer-First Focus → Speakeasy is built with API consumers in mind, ensuring the SDKs are easy to use, maintain, and integrate into existing projects.

• Built-In API Documentation → Generates comprehensive API documentation alongside SDKs, making it easy for developers to understand and use the API.

• API Analytics and Observability → Provides insights into how your APIs and SDKs are being used by consumers.

• Lightweight Tooling → Speakeasy is designed to be lightweight and easy to adopt, with a modern CLI and APIs for quick setup and management.

The first step is to install the Speakeasy CLI client. Fortunately, this can be easily done using Homebrew. Simply run the following command:

brew install speakeasy

This will set up the Speakeasy CLI on our system, allowing you to start working with it right away. Brew makes the installation process quick and hassle-free!

Once the installation is complete, the next step is to initialize Speakeasy by running the following command:

speakeasy quickstart

This command guides you through the setup process, making it easy to get started with Speakeasy. It’s designed to help you configure everything you need in just a few simple steps!

After running the speakeasy quickstart command, we’ll be prompted to select our workspace. Simply choose the appropriate workspace for our project, and once that’s done, you can return to the CLI to continue with the setup process. It’s a smooth and straightforward workflow designed to keep things efficient!

Selecting our workspace

Select OpenAPI Document Location

Naming our SDK

Choosing our language

Choosing the package name

Output directory for the generated SDK

Initilizing Git repo

Python SDK Generated

All done!

Back in the CLI, navigate to the dune-quotes-python folder using the following command:

cd dune-quotes-python

Once you’re in the folder, run the following command to install the necessary dependencies:

poetry install

This will ensure that all required packages are installed and our Python environment is properly set up, making it ready to work with the generated SDK:

from dune_quotes import DuneQuotes

client = DuneQuotes()

quotes = client.get_api_v1_quotes()

for quote in quotes:
    print(f'#{quote.character} ==> #{quote.quote}')

Speakeasy generated Python SDK

All good, but where’s the documentation? How are our users going to know how to use our API? Well, that’s easy. We just need to browse the generated folder and we will find the docs folder and inside the sdks folder and inside the duneQuotes folder and finally inside an README.md file:

Generated Documentation for the SDK

While the process was relatively straightforward, I found it to involve quite a few steps. Personally, it felt a bit more complex than I would have liked because there were so many steps for something that could had been just a single form instead of multiple screens, but that might just be my perspective. For someone looking for a quicker setup, the number of commands and configurations might feel a little overwhelming.

Kiota

A command-line tool for generating an API client to call any OpenAPI-described API you’re interested in.

• Idiomatic SDK Generation → Supports multiple programming languages, including .NET, CLI, Go, Java, PHP, Python, and TypeScript.

• Strong Typing and Validation → Generates SDKs with strongly-typed models to minimize runtime errors and improve code reliability.

• Optimized for Microsoft Ecosystem → Initially designed to generate SDKs for the Microsoft Graph API, making it highly optimized for APIs with complex schemas.

• Open Source → Fully open-source with an active development community.

• Lightweight CLI Tool → Provides a simple and easy-to-use command-line interface (CLI) for generating SDKs.

Each programming language comes with its own specific set of instructions for setup and usage. Since there isn’t a predefined guide for Ruby, we’ll go with Python instead. Python’s instructions are well-documented and straightforward, making it a practical choice for this demonstration.

Let’s kick off by creating a brand-new folder to organize our project. We’ll name it kiota-duneQuotes to keep everything neat and aligned with the theme. To do this, simply run the command mkdir kiota-duneQuotes. This will generate an empty folder in the current directory, ready to house all the necessary files for our task.

Next, we need to transfer the OpenAPI specification, DuneQuotesSpec.yaml, into our newly created folder. This step ensures that all our resources are in the right place and easily accessible for the next stages of the project. To achieve this, use the command:

cp DuneQuotesSpec.yaml kiota-duneQuotes

Which will copy the spec into the kiota-duneQuotes folder.

Now, we have the groundwork set up and the OpenAPI specification safely stored in its designated directory, ready for further exploration and development.

We need to run the following commands to get the required dependencies:

pip install microsoft-kiota-abstractions
pip install microsoft-kiota-http
pip install microsoft-kiota-serialization-json
pip install microsoft-kiota-serialization-text
pip install microsoft-kiota-serialization-form
pip install microsoft-kiota-serialization-multipart

Before we dive any deeper into the process, there’s one crucial step we need to address: installing Kiota itself. While there are several ways to go about this, for the sake of simplicity and efficiency, we’re going to choose the method of using the Kiota binaries. This approach allows us to quickly set up Kiota without getting bogged down in dependencies or complex configurations.

To get started, we’ll download the Kiota binaries, ensuring that we have the right version for our operating system. Once the binaries are in place, we’ll be able to run Kiota commands seamlessly and proceed with generating our SDK without any interruptions.

Now that we’ve set everything up, we’re all set to generate the SDK files. This is the exciting part where the tools come together and start creating the necessary code for our project.

To generate the SDK files, we’ll use the kiota generate command, which will take the OpenAPI spec we’ve stored in the kiota-duneQuotes folder and generate a Python SDK for us. The command we’ll run is as follows:

kiota generate -l python -c PostsClient -n client -d DuneQuotesSpec.yaml -o ./client

Once the SDK is successfully generated, we can move on to the next important step: creating our test file. This test file will allow us to validate the functionality of the generated SDK, ensuring everything is working as expected and that we can interact with the API seamlessly.

We’ll need to create a new file where we can write our tests, using the SDK methods and functionality we’ve just generated. This will allow us to simulate interactions with the API, test various endpoints, and check for expected behaviors in a controlled environment.

By setting up a test file, we can catch any potential issues early and ensure that our SDK integrates smoothly with the rest of the application. Let’s proceed with creating the test file and diving into the testing process.

import asyncio
from kiota_abstractions.authentication.anonymous_authentication_provider import$
    AnonymousAuthenticationProvider)
from kiota_http.httpx_request_adapter import HttpxRequestAdapter
from client.posts_client import PostsClient

async def main():
    auth_provider = AnonymousAuthenticationProvider()
    request_adapter = HttpxRequestAdapter(auth_provider)
    client = PostsClient(request_adapter)

    quotes = await client.api.v1.quotes.get()

    for quote in quotes:
        print(f'#{quote.character} ==> #{quote.quote}')

asyncio.run(main())

Kiota generated Python SDK

While generating the SDK was a relatively straightforward process, integrating it into our sample script proved to be a bit more challenging. It took me some time to figure out the correct structure and how to properly invoke the SDK in our code. The complexity arose because the generated files weren’t immediately intuitive, and the documentation to guide us through this process wasn’t readily available.

I also ran into another roadblock: I haven’t been able to find any clear documentation on how to generate or access the documentation for the SDK itself. This lack of generated docs makes it a bit harder to understand the methods and properties available within the SDK, leaving us to rely more heavily on the generated code and trial-and-error to figure things out.

Despite these hurdles, I’ve been working through the process, experimenting with the generated files to uncover the right structure and method calls. It’s a bit more manual than I anticipated, but with persistence, I’m confident we can get it all running smoothly. If I do find a way to generate documentation or discover any helpful resources, I’ll be sure to share them to streamline the process moving forward.

AutoRest

Generate code from your OpenAPI definition using AutoRest

• Multi-Language SDK Generation → Support for Python, C#, Java, TypeScript, Go, and PowerShell. Swift is coming.

• API Documentation Generation → Generates API documentation alongside SDKs in various formats (Markdown, HTML, etc.).

• Built-in Azure Support → Provides out-of-the-box integration with Azure SDKs and can generate Azure-specific client libraries.

• Strong Typing and Validation → Generates strongly-typed models and client code, reducing runtime errors and improving code reliability.

• Integration with CI/CD → Easily integrates with CI/CD workflows to ensure that SDKs and client libraries are kept up to date with API changes.

Let’s kick things off by installing AutoRest, a powerful SDK generation tool. Thankfully, the installation process is straightforward and can be done directly from the terminal. Simply run the following command:

npm install -g autorest

This command installs AutoRest globally on our system, making it accessible from anywhere in our terminal. Once installed, you’ll have all the tools you need to start generating SDKs efficiently. Let’s complete this setup so we can move on to exploring AutoRest’s capabilities!

Now, let’s generate a Python client using AutoRest. This process will take our API specification and create a fully functional SDK for interacting with it. To do this, run the following command in our terminal:

autorest --input-file=DuneQuotesSpec.yaml --python --output-folder=RestQuotes

Once you run this command, AutoRest will work its magic and generate a Python client within the RestQuotes folder.

Running AutoRest and getting some erros

Except, things didn’t go as smoothly as expected — AutoRest threw some rather cryptic errors during the generation process. At first glance, it wasn’t immediately clear what was causing the issue.

After some digging and troubleshooting, I discovered the root of the problem: each operation in the OpenAPI specification needs to have its own operationId tag. Without this, AutoRest struggles to correctly map and generate the SDK methods. This was unexpected, especially since other SDK generators I’ve used didn’t require this level of specificity.

While it caught me off guard, it’s not a showstopper. Adding unique operationId tags to the spec is a manageable fix, and once addressed, AutoRest should function as intended. It’s a small extra step, but one worth noting for anyone planning to use AutoRest with their OpenAPI specs.

Running AutoRest

With the operationId issue resolved, everything is back on track! The SDK has been successfully generated, and the output is neatly organized in the specified folder. We’re now ready to dive in, explore the generated files, and start integrating the SDK into our project. It’s great to see things running smoothly again!

Next, we’re ready to test our newly generated SDK client by creating a simple script. However, here’s where another hiccup surfaced. While preparing the script, I realized that the SDK depends on additional Python packages — but this wasn’t mentioned anywhere in the documentation!

To get the SDK client working properly, you’ll need to install the following dependencies:

pip install isodate
pip install azure-core

Now, it’s time to test our generated SDK with a simple test script. However, before we can run the script, there’s one more dependency we need to address. Since the SDK is built with Microsoft’s ecosystem in mind, you’ll need to install the azure-identity package to handle authentication.

You can do this easily by running the following command:

pip install azure-identity

This package provides essential authentication methods, such as support for Azure Active Directory credentials, ensuring our SDK can securely connect to the API.

While it’s another dependency to manage, it’s a necessary step to make the SDK functional. Once installed, we’ll be ready to dive into testing our script and seeing the SDK in action!

from RestQuotes import DuneQuotesAPI
from azure.identity import DefaultAzureCredential

client = DuneQuotesAPI(credential=DefaultAzureCredential())
quotes = client.get_quotes()

for quote in quotes:
    print(f'#{quote['character']} ==> #{quote['quote']}')

When it comes to documentation, I ran into a bit of a roadblock. Despite thoroughly exploring the available resources, I couldn’t find any clear instructions or guidance on how to generate documentation for the SDK.

This lack of information can be frustrating, especially for developers who rely on good documentation to understand and utilize an SDK effectively. It’s something that stands out compared to other SDK generator tools, many of which either generate documentation automatically or provide a straightforward way to do so.

If this feature exists, it’s not well-documented, which makes it harder to leverage the full potential of the generated SDK. Hopefully, future updates to the tool or its documentation will address this gap.

Conclusion

After thoroughly testing various SDK generation tools, here are my key takeaways for each of them:

Fern
Hands down, one of the best experiences I had. The entire process — from SDK generation to testing and documentation — was seamless. Fern was quick, intuitive, and required no extra steps for documentation generation. While some might criticize the lack of a UI, I appreciate Fern’s simplicity through a CLI installed via NPM — it appeals to my inner developer who wants to get straight to the point.

APIMatic
The SDK creation process was smooth and straightforward, just a great experience. Generating both the SDKs and documentation in a single step made for an excellent user experience. I thoroughly enjoyed the process.

OpenAPI Generator
The SDK creation process was simple and intuitive. However, calling it from a test script wasn’t as smooth as I had hoped, requiring a bit of extra effort to get things working because the source code was a bit too complex for my taste. On the bright side, its documentation generation was solid and sufficient for most use cases as it’s an HTML page with all the information about the generated SDK, although without any formatting or design.

Stainless
The SDK generation process was smooth, and having the generated SDK pushed to GitHub, complete with usage examples, was a nice touch. It’s a private repo on their organization which can be transferred to a production repo of our own. However, I couldn’t find any documentation generated for the SDK, which was a bit disappointing.

Speakeasy
While I didn’t enjoy navigating through multiple screens during the setup process, the overall experience was straightforward. It took me some time to locate the generated documentation, but it was there in the end.

Kiota
Kiota required installing several additional Python packages, which felt unnecessarily complicated. Moreover, the structure of the test script wasn’t user-friendly for me, and the lack of documentation for the generated SDK was a significant downside.

AutoRest
The issue with missing operationId tags in the OpenAPI spec caused some initial frustration and wasted time. However, once resolved, the process was smooth. Testing the generated SDK required an extra library installation, but this wasn’t a major obstacle. Unfortunately, like Kiota, I couldn’t find a way to generate documentation for the SDK.