Database assertions in API tests — close the loop between HTTP and your data

A POST request that returns 201 Created doesn't prove data was written. Your API might return 201 and silently fail to commit, or write to the wrong table, or insert a row with null values for required fields. A green status code is a necessary condition for a passing test — not a sufficient one. Rostyman's DB Verify tab adds the missing half: a SQL assertion that runs immediately after the response arrives.

The gap in most API test suites

Typical API test scripts check the response: status code, response body shape, specific field values. That's useful and worth having. But it only validates what the API claims happened. To know what actually happened in your system, you need to check the source of truth — the database.

Most teams work around this by running a separate database query in their CI script, or checking the database manually after sending a request. It works, but it's manual, it breaks the flow, and it rarely makes it into automated tests because the overhead of setting up a database assertion in a separate tool is high enough that teams skip it.

How DB Verify works

Open any HTTP request in Rostyman and click the DB Verify tab. Select a database connection (any of the 8 supported drivers), write a SQL query, and set an assertion: row count equals 1, specific field equals expected value, count increased by 1. When you click Send, Rostyman executes the request, waits for the response, then immediately runs the SQL query and evaluates the assertion. Pass or fail is shown right below the response, with the full query result one click away.

The assertion runs on every Send — not just on demand. Once you wire it up, it becomes part of the request, version-controlled with your collection, running automatically whenever a teammate sends the same request.

Practical examples

A POST /users endpoint: assert that SELECT count(*) FROM users WHERE email = '[email protected]' returns 1 after a successful creation. A DELETE /orders/123: assert the row no longer exists. A PATCH /products/5: assert the price column reflects the updated value. A payment webhook: assert a transactions row appeared with the correct amount and status.

You can use environment variables in the SQL query — {{userId}} resolves from the active environment just like it does in request URLs and bodies. If the API response sets a variable (via rm.environment.set() in a post-response script), that variable is available in the DB assertion SQL too.

In browser tests too

The same capability extends to browser tests. An assertDB step inside a browser test binds a database connection and runs a SQL assertion at any point in the test — after a form submission, after a button click that triggers a background job, after a UI action that should update a row. You're asserting what the user sees and what the database contains, in one test, without a second tool.

Why this matters

Most API bugs aren't in the status code. They're in the data — a field that doesn't get written, a constraint that doesn't get enforced, a cascade that fires when it shouldn't. A test suite that only checks HTTP responses misses an entire class of correctness errors. DB Verify makes database assertions as easy to add as a header check — no second tool, no SQL client, no manual verification loop.