When you need to integrate with a third party API, conventional wisdom is clear: don’t reinvent the wheel. Use the library. Benefit from community maintenance, battle-tested code, someone else’s bug fixes.
But sometimes the wheel you’re importing is a lot bigger than the wheel you need.12
Perhaps the library you find has a decent amount of stars on GitHub, perhaps it’s referenced in the API docs, perhaps even as an explicit recommendation by the company that owns the API.
But now you’ve got a dependency. And you’ve got their dependencies. You’ve got their update schedule and their attack surface. For what? Often just a thin wrapper around a few HTTP requests you could write yourself in a few minutes.
If you’re using three endpoints, do you need a library that wraps three hundred? Every endpoint you’re not using is code you’re shipping anyway. Code that could break/have vulnerabilities and you’ll never look at until something goes wrong.
The tradeoffs are real, and they’re not always in the library’s favour…
Maintenance: The library might break when the API changes. But so will your code. The difference is that with your code, you know where to look. You’re not waiting for a maintainer to wake up and put out a release.
Transitive dependencies: If the wrapper pulls in five other packages, they’ll each have their own vulnerabilities and update cycles.
Trust: Who maintains this package? When was it last updated? How many people have access? Is it one maintainer who lost interest two years ago? Is it a third party that the API company recommends (at time of writing) but doesn’t control?
And what happens when that recommendation disappears? One day the docs just stop mentioning it. No explanation, just “reasons.” Now you’re scrambling to figure out if that means “we’re building our own SDK” or “we found something bad in there, good luck” You’re left wondering if you should have just written the three HTTP requests yourself from the start.
There are also cases where the library earns its keep.
If authentication is genuinely fiddly (OAuth flows, token refresh, request signing), a well-maintained library saves real pain. If the API has complex retry logic, rate limiting, or pagination that’s easy to get wrong, let someone else get it right.
For the likes of AWS or Stripe, use the official SDK. These are well-maintained, well-documented, and handle complexity you don’t want to reimplement.
But for “some startup’s API with a community wrapper that has 200 GitHub stars”? Maybe just write the requests yourself. You’ll end up with less code, fewer dependencies, and a smaller surface area for things to go wrong.
This isn’t “never use libraries.” It’s “think about what you’re actually getting.”
If the library does meaningful work, use it. If it’s a thin wrapper around requests you could write yourself, consider whether the dependency is worth it.