In Depth: Speakeasy vs APIMatic

Nolan Sullivan

April 17, 2025 - 5 min read

---

At Speakeasy, we create idiomatic SDKs in the most popular languages. Our generators follow principles that ensure we create SDKs that offer the best developer experience so that you can focus on building your API, and your developer-users can focus on delighting their users.

In this post, we’ll compare TypeScript SDKs created by Speakeasy to those generated by APIMatic.

SDK Generation Targets

At Speakeasy, we believe it is crucial to meet your users where they are by supporting SDKs in languages your users depend on. Anyone who has had to maintain custom SDK code because a vendor doesn’t support their tech stack knows how frustrating this can be.

This table shows the current, as of September 2024, languages and platforms targeted by Speakeasy and APIMatic. These lists will change over time, so check the official documentation for the latest language support.

We’re always open to expanding our language support, but would only ever do this if we have the in-house experience to create idiomatic, best-in-class SDKs for a given language. Let us know if you would like to suggest a language or platform to support.

SDK Features

The table below compares the current SDK features offered by Speakeasy and APIMatic as of September 2024. Both Speakeasy and APIMatic are under active development, so these features may change over time.

APIMatic lacks advanced SDK customization features, and we couldn’t find any code or documentation related to pagination. These are features Speakeasy’s users rely on.

Platform Features

Speakeasy’s primary interface is an open-source, full-featured, and portable CLI. Developers use our CLI to experiment and iterate locally and to customize their CI/CD workflows.

APIMatic’s CLI depends on Node.js and several packages. This makes it much less portable. In testing, we also found that it does not generate SDKs as reliably as the APIMatic web interface.

Enterprise Support

Both Speakeasy and APIMatic offer support for Enterprise customers. This includes features like concierge onboarding, private Slack channels, and enterprise SLAs.

Pricing

Speakeasy offers a free plan, while APIMatic offers a limited free trial.

Speakeasy’s free plan is more generous than both Lite plans offered by APIMatic.

Speakeasy vs APIMatic Technical Walkthrough

Dependencies and SBOM (Software Bill of Materials)

From day one, Speakeasy has prioritized efficiency, and we’ve kept the dependency trees for our generated SDKs as lean as possible. For example, here’s the dependency graph for the Vercel SDK , an SDK generated by Speakeasy. It has zero direct dependencies, and one peer dependency (Zod).

By contrast, here’s the dependency graph for the Maxio SDK , an SDK generated by APIMatic. It has many dependencies, which in turn have transitive dependencies, leading to a much more bloated SDK that is harder to maintain.

Having more dependencies isn’t only bad in terms of efficiency. Many libraries single or no active maintainer. Many dependencies also have unaddressed critical vulnerabilities (CVs), leaving the upstream SDK vulnerable as well (the Maxio SDK has 4 of these ).

Bundle size

Dependencies aren’t just a security risk. They also bloat the size of your SDK. Here’s a comparison of the bundle sizes for libraries generated from the same OpenAPI spec by Speakeasy and APIMatic:

That bundle size is a problem if you have customers that need to integrate with your API in runtimes where performance is critical (browser and on the edge).

Type safety

Speakeasy creates SDKs that are type-safe from development to production. As our CEO recently wrote, Type Safe is better than Type Faith.

Speakeasy uses Zod  to validate data at runtime. Data sent to the server and data received from the server are validated against Zod definitions in the client.

This provides safer runtime code execution and helps developers who use your SDK to provide early feedback about data entered by their end users. Furthermore, trusting data validation on the client side allows developers more confidence to build optimistic UIs  that update as soon as an end user enters data, greatly improving end users’ perception of your API’s speed.

APIMatic will only be validated on the server. This means that the error will only be caught from the client’s perspective after the data is sent to the server, and the server responds with an error message.

As a result, developers using the SDK generated by APIMatic may need to write additional client-side validation code to catch these errors before they are sent to the server.

Discriminated Unions

Our OpenAPI document includes a Book component with a category field that can be one of three values: Programming, Fantasy, or SciFi.

This allows us to type the Book component in requests and responses as specific book types, such as ProgrammingBook, FantasyBook, and SciFiBook.

OpenAPI supports discriminated unions using the discriminator field in the schema. Here’s an example of a response that returns an array of books of different types:

Let’s see how the SDKs handle this.

Speakeasy generates TypeScript types for each book type, and uses a discriminated union to handle the different book types. This enables developers to use the correct type when working with books of different categories. This pattern could just as easily apply to payment methods or delivery options.

The example below shows how Speakeasy defines the ProgrammingBook type. It also generates types for FantasyBook and SciFiBook.

In this example, you’ll notice that the category field is optional in the ProgrammingBook type, but is enforced by Zod validation in the SDK.

We can see how Speakeasy generates SDK code to handle the different book types in the response for the getgetAllBooks operation:

Note how the array elements in responseBodies are typed according to the book category.

This may seem like a trivial example, but it illustrates how Speakeasy generates types that are more specific and easier to work with than the types generated by APIMatic. This could, for instance, help developers correctly handle different book types in their applications.

APIMatic does not generate types for discriminated unions, and developers must manually handle the different book types in the response.

Here is the equivalent type definition generated by APIMatic:

Following the CategoryEnum import:

Discriminating between different book types in the response is left to users.

Speakeasy Compared to Open-Source Generators

If you are interested in seeing how Speakeasy stacks up against other SDK generation tools, check out our post.