For years my API testing workflow looked like this: open an API client, build the request, check the response, and promise myself I’d “write a proper test later.”

Later never came.

The requests I checked by hand once were never checked again. Then a small refactor broke an endpoint, and nobody noticed until a customer did.

The problem is not the API client

Tools like Postman are great for poking at an endpoint. So is plain cURL. Right-click a request in the browser’s Network tab, copy it as cURL, paste it into a terminal, and you have your answer in seconds.

But both approaches have the same gap. They tell you the endpoint works right now. They don’t turn that check into something that runs again tomorrow, on every pull request, without you thinking about it.

There’s no shortage of API testing automation tools that promise to fix this, but most of them still expect you to write and maintain the tests yourself. Writing those tests by hand is the part everyone skips. You need realistic payloads, you need to stub the database and every downstream service, and you need to keep all of it updated as the code changes.

Recording real traffic instead

What finally fixed this for me was flipping the approach. Instead of writing tests, I record them.

Keploy is an open-source tool that sits next to your app and captures the real API calls it handles, including the database queries and calls to other services behind them. It then turns that traffic into test cases and data mocks automatically. There’s no SDK to add and no code to change.

Setup is a single install command (instructions are on keploy.io), and the workflow after that is short. Start your app in record mode:

keploy record -c "go run main.go"

Then use the app the way you normally would. Hit the endpoints with cURL, your API client or your frontend. Every request and response is saved as a test, and every dependency call is saved as a mock.

When you want to check for regressions, replay everything:

keploy test -c "go run main.go" --delay 10

Keploy replays the recorded requests against your app, serves the recorded mocks instead of the real database and services, and flags anything that changed.

Why this works better for me

The tests are realistic. They come from real requests, not from payloads I invented at 6 pm on a Friday.

Mocks come for free. The slowest part of writing integration tests was always stubbing dependencies. Now that happens as a side effect of recording.

The checks I already do become permanent. The cURL request I would have run once and forgotten is now a test that runs in CI on every pull request.

It’s language agnostic. It works at the network level, so the same approach works across the Go, Node.js and Python services I deal with.

Where it fits in my workflow

I still use cURL to explore an endpoint for the first time. That hasn’t changed, and I don’t think it should. Quick, disposable checks are what cURL is good at.

The difference is what happens next. Once an endpoint behaves the way I want, I run through it with recording turned on, commit the generated tests, and move on. The manual check becomes a regression test in about the same time it took to do the check.

If you’re also tired of “I’ll write the test later,” it’s worth trying. Keploy has a good overview of automated API testing if you want to see how the record-and-replay approach compares with writing tests by hand.

Exploring an endpoint should be fast. Protecting it shouldn’t be extra work.

Disclosure: I work at Keploy.