Introducing Thirdparty

Building software is hard. Sure, AI has made it easier in many ways, but it’s still a complex, messy process. And to make things more interesting, most software doesn’t live in isolation, it often talks to other systems. Sometimes those are your own and you can control them, but more often than not they’re external, third-party APIs for things like getting data, authentication, or whatever else your app needs to function.

Now, here’s where things usually go sideways for me. When I’m developing locally, I constantly run into integration pain. Maybe my internet connection is unstable, so my tests fail because the API can't be reached. Maybe my code depends on an API that’s rate-limited, and I’ve hit the quota. Or maybe my auth token expired (again), and I need to go through the dance of renewing it. And sometimes, the service I’m working with just isn’t available.

After running into these issues too many times, I started writing little mocks to fake third-party API responses, just to keep building and testing without relying on the real service. I’d define fake responses based on documentation or old recorded payloads for the same requests, and that’s when the idea for Thirdparty was born.

Thirdparty is a lightweight Go service that uses a simple YAML configuration to define API endpoints, requests, and responses. You point your app to Thirdparty instead of the real service, and it replies exactly how you’ve configured it: fast, predictable, and offline. You can even simulate network slowness or timeouts to see how your code handles them.

What started as a quick personal fix ended up being surprisingly useful. I’ve used Thirdparty on client projects, integrated it into automated test suites, and even plugged it into a CI/CD pipeline. It’s saved me countless hours of frustration and now, I’m making it public in case it can do the same for others.

You can check it out and read more here: https://iferminm.gitlab.io/thirdparty/