
A Simple Way to Organize Third-Party API Responses for Testing
When working on projects that depend on multiple integrations with third-party APIs, sooner or later the challenge appears: how do you organize and maintain API mock responses in a consistent way?
In recent years, I worked on a project that integrated with several external providers — payment gateways, email delivery services, notification platforms, data lookup APIs, and more. Each integration had different response formats, directory structures, and ways of generating mocks for tests. Over time, this became a real problem.
The Problem
- Inconsistency – each developer created mocks in a different way, stored in different places.
- Hard to maintain – when an API’s format changed, finding and updating all the mocks was time-consuming.
- Low predictability – some tests failed because mocks weren’t organized or followed different standards.
- Unnecessary complexity – instead of focusing on the application’s logic, we were spending time hunting for mock files or adapting code to read responses in different ways.
The Motivation Behind the Package
That’s when I decided to create a package to address these issues: API Mocker 🚀
The idea was simple: have a single, consistent way to store, locate, and load third-party API responses in tests, using JSON in a centralized structure.
This way, regardless of the service being integrated — Stripe, PayPal, Twilio, SendGrid — the process of creating and using a mock would always be the same.
The Use Case
Imagine you have tests for three different integrations:
- Stripe for payments
- SendGrid for emails
- ViaCEP for address lookup
With the package, each provider has its own mock folder with clear scenarios such as success.json, error.json, or other meaningful names.
When a test needs to simulate a successful payment creation, you simply call the corresponding mock without having to remember where the file is or how to load it.
This standardization makes it easier to:
- Quickly create new mocks.
- Simulate different scenarios (success, error, validation).
- Keep everything organized even with dozens of integrations.
- Ensure predictability and consistency in your tests.
The Outcome
After adopting this approach, our tests became:
- Faster – no dependency on real API calls.
- More reliable – mocks are centralized and version-controlled.
- Easier to maintain – all follow the same structure.
API Mocker was born from a real-world need and is now available as open source for any PHP project that needs to deal with external integrations while keeping tests clean, organized, and predictable.
💡Package Link: https://github.com/ranierif/api-mocker
Published on August 9, 2025