Testing APIs shouldn’t feel like a chore. Yet, here we are, copy-pasting URLs into Postman, manually typing headers, rebuilding request bodies from scratch, and constantly switching between our code and external tools. It’s 2025, and we’re still doing this.
What if your API client just… knew about your Laravel app?
That’s Nimbus. An integrated, in-browser API client that automatically discovers your routes and validation rules, understands your authentication, and gives you an interface to test everything without leaving your development environment.
The Problem With Traditional API Clients
Don’t get me wrong, tools like Postman and Insomnia are great tools. I have been using them all this time. But they’re built for a different problem; they’re generic clients meant to work with any API, anywhere. That generality comes at a cost: everything is manual (including the creation of scripts manually).
Think about your daily workflow:
You build a new endpoint in Laravel. You define the route, write the controller, and create a Form Request with validation rules. Then you switch to your API client and… start from scratch. Copy the URL. Type the method. Add headers one by one. Build the request body by guessing what fields you need. Send the request. Get a validation error. Go back to your code to check the validation rules. Update your request. Try again. Then, once done, you have to figure out how to communicate it with the rest of the team.
That’s a lot of friction and wasted time.
Here’s the thing: your Laravel application already knows everything about your API. It knows the routes, the validation rules, the authentication requirements, and the response structure. Why are we manually reconstructing this information in an external tool?
That was what I was asking myself every time I was fiddling with these tools. Which made me think, why not make it happen?
Meet Nimbus
Nimbus takes a different approach: instead of being a generic API client, it’s a Laravel-aware API client. It lives inside your application and automatically understands what you’re building.
Here’s what happens when you install Nimbus:
- It scans your API routes.
- It extracts validation rules from Form Requests and inline validators.
- It builds JSON schemas automatically.
- It gives you an interface to test everything.
That is it. No collections to maintain. No manual syncing. Just install and start testing.
Want to see it in action before installing? Try the live demo. No setup required.
The Magic of Laravel-Awareness
Being inside your Laravel application gives Nimbus superpowers that external clients can’t have:
- Session-based authentication
- User impersonation
- Cookie inspection
Let me show you what this means in practice.
Setting up a new endpoint?
With traditional tools, you manually configure everything: copy URLs, set HTTP methods, add headers one by one, and build request bodies by guessing field names. With Nimbus, routes are discovered automatically.
Updating validation rules?
Changed a field from optional to required? With traditional tools, you need to manually update your collection and sync it with your team. With Nimbus, the changes appear immediately. It reads directly from your validation rules.
Testing authenticated endpoints?
Traditional tools require extracting tokens, managing expiration, and manually adding authorization headers. Nimbus lets you authenticate with one click, either as your current user or by impersonating any user ID. No token management needed.
Debugging cookies?
Need to inspect a Laravel session cookie? With external tools, you copy the encrypted value, find (or make) a decoder, paste it somewhere, and try to make sense of it. Nimbus decrypts and displays your cookies automatically.
Sharing with your team?
Traditional tools require exporting collections, sending files around, and hoping everyone imports the latest version. With Nimbus, there’s nothing to share. Everyone on the team just visits /nimbus in their local environment. No exports, no imports, no version mismatches.
--
And honestly, the sky is the limit. The package embraces a “not afraid of magic” philosophy, and anything that we can do to make the Developer Experience much better, we will do.
What Nimbus Is Not
Let’s be clear about this: Nimbus is not an API documentation generator.
It doesn’t produce beautiful, client-facing API documentation. It’s not trying to replace tools like Scribe or Scramble. Its sole purpose is to improve the developer experience while building and testing APIs.
Think of it as a developer-focused API playground, not a production documentation tool.
Getting Started
Installation takes less than a minute:
composer require sunchayn/nimbus
php artisan vendor:publish --tag=nimbus-assets --tag=nimbus-config
That’s it. Navigate to http://your-app.test/nimbus and start testing.
Nimbus is currently an open alpha release. This means:
- You might encounter bugs or unexpected behaviors.
- Some edge cases aren’t handled yet
- Performance could be better for large applications
- Features are intentionally minimal to validate the concept.
I’m releasing it as alpha to validate whether this approach resonates with the Laravel community. Does automatic schema discovery actually improve your workflow? What features would make it indispensable?
Closing Notes
We spend so much time building APIs in Laravel. Yet we’ve accepted that testing them requires leaving our environment, reconstructing our routes manually, and fighting with external tools that don’t understand our application.
Nimbus is my attempt to eliminate that friction. Give it a try.
Links:
- Documentation: User Guide
- Want to contribute? Check the contributor guide
- Found a bug? Open an issue
- Have a feature idea? Start a discussion
Thanks for reading!
Top comments (13)
While I applaud the effort and I see the appeal of a playground, I think tests provide more robustness.
Maybe the library should have the option to generate tests?
Thanks for commenting! Nimbus is not meant to replace testing. They are not mutually exclusive and serve different purposes. It is meant for flows like when you want to quickly interact with an endpoint, a frontender wants to check endpoint content and interact with them when they are working on the client side of the feature, a QA wants to run pre-conditions by interacting with the APIs, etc. These things cannot be done via testing suites (integration + unit tests).
I understand it is not replacing testing. My idea for the generating test option came because the context of the endpoint is known in your library. And it can change on the fly, so that could be great to make sure tests are checking the actual features.
In the frontender case the output should be communicated. If the output is not what is communicated the fault is with the backend. They can check the output when they debug the API request, no need to enable the library.
For the QA situation, do you want QA's to set up the project on their own computer? My experience with QA people is that they test on the acceptance/test environment. If the library is enabled on a server it is used too far in the development process.
You can write end to end tests if there are situations that you can't test with less expensive tests. If you can't write tests, how can you be sure the features will keep on working in the future?
Thanks for the insight!
The philosophy of the package is to do one thing and do it well: be a playground for API interaction. Adding test generation would drift from this core purpose. Nimbus focuses on the immediate "I want to see what happens when I send this request" moment during development.
Absolutely, but documentation and real interaction serve different purposes. Even with perfect docs, developers often need to:
This is also valuable when you're NOT doing TDD, you write the code, want to see it work, then write tests. Nimbus fits that exploratory phase.
Not necessarily a local setup, as you mentioned, it can be enabled on staging environments if your organization allows it. But you're right that this is optional. The primary audience is developers during active development.
To clarify: Nimbus isn't a replacement for tests. It is about having a PLAYGROUND. It's for the exploratory phase before you write tests, or when you're iterating quickly and just want to see if something works, or when you just want to interact with an endpoint for whatever reason. Think of it like using dd() or var_dump(), you're inspecting behavior, not ensuring correctness long-term.
I have no problem with that stance. I was just thinking out loud about the testing option.
The real interaction is when you write the tests. If you need to mock a lot of things then you have a problem with the design of the code.
Write tests and if they fail fix te code. You don't need to do TDD. You can write the code and add the tests after you written the code. Why would you do a manual test and then write a test, work smarter not harder.
That was my point, your library shouldn't be enabled on a server.
I didn't check if the endpoint for the playground needs authorization or not. But even if it does it means the code is going to production, and that could become a data leak in the worst case.
My end to end test statement is not about the library but about good code practices.
I think you did a good job with the library, I just wanted to point out a few of the consequences when adding the library.
That’s not entirely accurate. A test will never represent a real interaction. Tests validate expectations; they don’t simulate the full behavior of an active system.
That approach can work, but inspecting responses through tests alone is often inefficient, especially during early development. The point of a playground isn’t to verify correctness; it’s to explore behavior against real data and context. The distinction between a Playground and Automated Tests is important here.
Developers can use it briefly during early development, or later if they need to interact directly with an endpoint with as little friction as possible and with as much kickstart as possible. It’s flexible and can be tailored to whatever needs you have.
Correct. Nimbus supports environment-based control. It’s disabled in production by default.
If preferred, it can also be installed as a development dependency via:
Tests should represent real interactions, if hope you are not only writing happy path tests. But they should intercept the interaction on the lowest level, so that it is not needed to create more expensive tests.
Don't do end to end tests, do transformer tests. If you are writing an endpoint and only test the output, that will take longer than testing each part that makes up the endpoint separate.
That was my point. The code should not be on a production server, not even disabled. That is the same as keeping the test code on production. The only thing that is does is creating a potential cause for problems.
I think there’s some confusion about the intent of this package. It has nothing to do with automated testing, CI, or TDD practices.
Nimbus is an in-browser API client, similar in concept to Postman or Insomnia, but it operates within your Laravel codebase. That integration gives it advantages that external tools can’t provide, such as automatic route and payload discovery, cookie decryption, user impersonation, and making requests as the currently authenticated user.
There’s no disagreement on the value of tests or coverage depth. However, that’s separate from what Nimbus is designed for. Automated tests validate expected behavior. A playground is about direct interaction: running endpoints manually, seeing real responses, and observing side effects against actual data. It’s a complementary tool, not a replacement for tests.
I don't want to dictate what people should do. By default, Nimbus is disabled in production. It can be explicitly enabled only when needed. For example, in a controlled internal environment behind role-based middleware or a VPN. One use case can be to debug production issues or to inspect session state by impersonating a user. Whether to allow that flexibility is a decision for each organization to make. But if they want to, they should be able to.
There is no confusion. I just reacting on you statements about testing.
The data input is also an expectation so it doesn't matter if you get the full response or just raw data from the database or a test set. It are always fun times when you let a test framework run mutation tests.
Side effects can be checked with integration tests.
The only time you have actual data on your computer is when you connect to a production database. And you only want to do that to check data fetching queries, not data manipulating queries.
It might be convenient to have a playground for instant gratification, but I think it promotes bad practices. Like it works on my computer.
That is a good mindset. It is the developers responsibility use the library wisely.
I just wanted to add a warning for people that didn't think of that consequence.
Fair! I only mentioned testing because you brought it up. The point I wanted to clarify is that testing and the package’s purpose are not mutually exclusive. They serve different goals.
Why is this? A Playground is inherently personal. It’s not meant to prove correctness or enforce practices. It’s about convenience for developers to execute endpoints quickly. Nimbus is simply an alternative to Postman, Insomnia, etc., designed to give a head start with less friction.
The fact that similar tools have millions of users shows that many developers find them valuable. Here is also open source famous tools:
The core idea is straightforward: if you want a fast, integrated way to explore your Laravel endpoints, a Playground exists to make that process easier. Nothing more, nothing less.
I think the main task of Postman and alternatives is to create interactive documentation. I think it is better to generate industry standard documentation and interaction, like OpenAPI and Swagger.
With a playground there just is the interactive component. Which means the developers don't need to do the documentation part. It is not the library I am against, it is the possibility to take shortcuts.
It is not because something is popular that it is the best tool.
I think we can agree to disagree here. In my experience, there have been many situations where a playground was genuinely useful. Even with comprehensive documentation and 100% test coverage (including mutation testing), there were moments when interacting directly with the endpoint was more convenient.
If you don’t see the value for your workflow, that’s completely fine; but many developers do find this kind of tool helpful in practice.
That's on developers, not the tool. I stated in many places in the wiki and article that it is not meant to replace documentation tools, it is not meant for production, and is solely a playground tool. For instance, in my current workflow, I have the OpenAPI documentation, Insomnia (now I'm using Nimbus), and tests (including mutation tests). They are not mutually exclusive.
In fact, I'm thinking about making OpenAPI schema an input for Nimbus, so it can read the routes and payloads from the documentation and give an interactive interface with the exclusive features that you can only get in an integrated package.
This looks awesome! Testing APIs inside the app environment feels like the upgrade we’ve been waiting for.
The validation rule auto-discovery and instant updates after edits — pure magic ✨
Can’t wait to try Nimbus and see how it changes my workflow.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.