API Spector is an API client and test runner from Testsmith. It sits in the same family as Postman and Bruno, but it keeps its workspace, collections and environments as plain, diffable JSON files. You get a graphical interface when you want to explore, a command line runner for pipelines, and a storage format that reviews cleanly in Git. The goal is to keep the comfort of a visual client without giving up version control.
How it works
A workspace file points at one or more collection files and one or more environment files. A collection holds a tree of folders and requests. Each request has the usual method, URL, headers and body, and it can carry scripts that run before or after the call. Scripting uses an sp object for tests, expectations and the response, so a post request script reads much like the assertions you would write in other clients:
const json = sp.response.json();
sp.test("Status is 200", function() {
sp.expect(sp.response.code).to.equal(200);
});
sp.test('access_token exists', function() {
sp.expect(json.access_token).to.not.be.oneOf([null, undefined]);
});
Variables let one request feed another. A login request can save the access_token into a variable with sp.variables.set, and a later request can send it as a Bearer token. You run everything with api-spector run against a workspace and an environment, and you get an HTML report out the other end. For interactive work there is api-spector ui.
Benefits
The JSON storage format is readable and version control friendly, so changes show up as small, understandable diffs. Having one tool that offers both a graphical view and a CLI means the request you built by hand is the same request that runs in CI, with no translation step. Environments keep the base URL and any secrets out of the individual requests, which keeps the collection tidy.
Downsides
API Spector is a focused, relatively new tool, so its community and third party material are smaller than those of the long established clients. The .spector format is its own, so your collections do not move directly into other tools. One practical warning that this example makes visible: the collection stores a collectionVariables.access_token value, and a saved token like that is an expired sample. Treat stored tokens as throwaway and always refresh them through a real login step rather than trusting a value baked into the file.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-api-spector tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, the ToolShop backend used throughout this series. The BASE_URL lives in environments/test.env.json.
Three scenarios are covered. GET /brands expects status 200 and at least two brands. POST /users/login expects status 200 and a non empty access_token. The Invoices folder uses a before hook that logs in and stores the token, then calls the protected GET /invoices endpoint with Bearer auth and checks the status. A GitHub Actions workflow installs the CLI, runs the workspace on push and always uploads the HTML report, even when a test fails. The scenarios match the Postman and Bruno examples on purpose, so you can compare the three JSON and text based clients directly.