When companies build a new service, they usually focus on getting an API and docs straight to the customer. They often forget about building a client library or SDK, thinking the docs and API suffice.

Launching an API without an SDK means every customer must implement their own SDK. From the user’s perspective, the burden of building and maintaining a core integration component is now squarely on their shoulders. This creates an obstacle to adoption and makes it harder for users to deeply integrate with the service.

Let's break down the technical burden that companies place on developers when an SDK is missing.

The User Implementation Checklist

Here’s a high-level, non-exhaustive list of what developers need to implement before they can start using a raw API with no SDK. While every case for every developer and implementation will differ, they will at minimum need to think about and implement huge portions of the following; greatly impacting their developer experience.

1. HTTP Client Configuration: Library choice, appropriate timeouts and retry rates, base URLs, path joining logic, and content headers.

2. Authentication Handling: The exact authentication scheme, refresh token expiry and update logic. If a service provides API keys or Bearer tokens that don’t need to be refreshed often, this is a small ask. If it’s an OAuth 2.0-like flow, then this can easily get complicated to implement properly.

3. Request Serialization & Formatting: Constructing request bodies and ensuring they adhere to the correct schema. Encoding query parameters. Handling pagination.

4. Response Deserialization & Parsing: Parsing responses into usable objects, handling every status code returned by the API, and handling the variations in response structures for different status codes.

5. Error Handling: Deciding how to handle each status code, implementing exponential backoff and jitter for rate limit errors, and defining custom exceptions specific to the service’s potential failures.

6. Type Safety & Data Modeling (in typed languages): Creating interfaces and classes to represent request, response, and error objects; and doing this while lacking autocompletion because APIs don’t have language server support.

7. Ongoing Maintenance: Monitoring changelogs and newsletters for changes to an API such as new endpoints, deprecated fields, or changes to requirements like rate limits. Then updating their implementations every time the API evolves; or preferring to stick to deprecated fields.

tip

Don’t let the user discover retry rates in production. Let the SDK enforce them from the start.

The Compounding Effect

This isn't a one-time cost. Every single team using an API without an SDK duplicates this effort. They build their own, slightly different, potentially buggier versions of what should be a standard interface layer. The quality varies wildly based on the developer's experience, available time, and the language/framework specifics.

The Inevitable Result

Faced with this significant upfront integration cost and ongoing maintenance burden, development teams will rationally choose the path of least resistance:

1. Reduced Adoption: The initial friction is higher. Integrating a new service looks more costly and time-consuming than alternatives, encouraging switching to competitors or potentially deterring adoption altogether. Time-to-first-call skyrockets.

2. Shallow Integration: Teams will implement only the bare minimum required for their immediate use case. Why invest in building robust handling for endpoints or features they don't need right now if it means writing more bespoke client code? This limits the value they derive from the platform, reducing potential stickiness and willingness to purchase additional features or upgrade to higher cost plans.

3. Inconsistent Implementations: Lack of an official SDK leads to divergent, potentially incorrect implementations across the API’s user base, making support harder and increasing the likelihood of users hitting unanticipated edge cases.

4. Increased Debugging Effort: Inconsistent implementations aren’t just an issue for users. They’re also an issue for companies when supporting those users as now there’s the added step of debugging the user’s own SDK implementation.

5. Unofficial SDKs: If an official SDK is unavailable, developers may resort to producing and using unofficial SDKs. This can be great in the short term but long term unofficial SDKs risk ending up out of sync with their APIs, missing features, lacking support, being abandoned, or worse transferred or sold to malicious maintainers. Long term unofficial SDKs lead to a fragmented ecosystem and difficulty trialing and integrating the service.

6. Lack of Client-side Analytics: Users may use an API or encounter issues with it in ways that are unexpected or impossible to measure server-side. Without an SDK there’s no way to gather these analytics.

SDKs Are Your Product

Your product may not be “SDKs”, but SDKs are your product. The only difference is who creates it: your company or your customers. Yes, building and maintaining SDKs requires effort from you, the service provider. But it's an investment in developer experience (DX) that pays dividends. You are concentrating the effort in one place, ensuring quality and consistency, rather than diffusing and multiplying that effort inefficiently across your entire user base.

Providing SDKs to your users abstracts away the boilerplate of handling HTTP, and the complexity of auth, serialization, and deserialization. It accelerates integration time and encourages deeper integration with your service. They improve discoverability since methods and classes in your SDK become instantly available in IDE autocompletion. They centralize maintenance and there’s only a single codebase to update when your API changes.

Stop thinking of SDKs as optional extras; nice-to-haves. They are a fundamental component of your service offering in a connected world. By providing them, you respect your users' time, lower the barrier to entry, encourage deeper integration, and ultimately drive more successful adoption of your platform. Don't force your users to build the integration tools that you should be providing.