Test what your API really did

Verify the side effects, not just the response

Tools like Postman and Bruno make it easy to assert on an API’s response, and for most teams that is where testing stops. But an API that changes something does more than respond. The change happens elsewhere, and it is already complete by the time the response arrives. A test that asserts only on the response can pass while no row reached the database and no message reached the queue.

For example, a single POST /shipments call can be verified end to end:

✓ HTTP response 201, with the new shipment id
✓ Row created in the SHIPMENTS table, status BOOKED
✓ Message published to the SHIPMENT.BOOKED queue
✓ Carrier API called with the weight and destination

API Test Base makes all four checks in one automated test case. See how API Test Base compares to Postman and Bruno.

Free and offline, on your own machine

No account, no cloud. You download API Test Base and run it on your own machine or in your CI/CD pipeline. Test cases are created with a no‑code / low‑code UI, so you can be productive in minutes.

Here is the UI, with a test case that has just been run:

Test APIs triggered by queue messages and file drops

Not every API is an HTTP endpoint. The same business logic may be triggered by:

• a message on a queue — IBM MQ, JMS, AMQP, or MQTT
• a file dropped on an FTP or SFTP server
• a SOAP call

API Test Base can send the trigger over the right protocol and then verify the outcome — so you can test the API the same way no matter how it is invoked. That makes it well suited to integration and ESB scenarios such as IBM MQ testing, JMS testing, SFTP testing, and SOAP API testing.

Built on a method: Integration Unit Testing

API Test Base is built around Integration Unit Testing — testing an API as a black box, in isolation, by testing both its spec (request and response) and its side effects (database records, messages, files, downstream calls).

Because the tests know nothing about the API’s internal code, they stay stable as the implementation changes. The same API tests you run by hand during development can be automated in a CI/CD pipeline to run the whole set on every build.

Learn more about Integration Unit Testing →

See it done on a real API, start to finish →

Built‑in test setup for integration testing

Integration tests need the right state before the API runs, and with most tools that means external scripts. API Test Base runs the setup directly inside the test. A typical database test is three steps in one case:

Database step
→ clear the table and insert a test record

HTTP step
→ call the REST API

Database step
→ query the table and assert the updated values

Setup isn’t limited to seeding data. For full isolation, a setup can stand up a dedicated stub database — a real database such as PostgreSQL, running in a throwaway Docker container — and create its schema and tables, so the API runs against state that’s entirely the test’s own. Structured test setup lets you define each setup once, reuse it across folders, and run only what’s needed.

Feature highlights

• Many protocols — not just HTTP
• No‑code / low‑code test case creation
• Standalone requests and structured test cases
• Built‑in data‑driven testing
• HTTP stubs (mock servers)
• Pattern‑based test case generation
• Automated test setup
• Docker support
• Git‑based team collaboration
• Offline‑first — all data stored locally

Ready to get started?

Download API Test Base and write your first test in minutes — then run the same tests in your CI/CD pipeline.

DownloadAutomate in CI/CD