Practical workflow

Verify database persistence after an API request

A POST response reports success and returns an order ID, but the database record is missing or has another value. Find that exact order and compare the persisted data with the requirement.

Checkcraft · 11 October 2026

Checkcraft Pro

This workflow needs an active Pro license and a build containing Pro scenarios. See the edition details.

Define what POST must persist

In this illustrative scenario, POST creates an order with total 300 and returns orderId ORD-1042. The agreed database result is an orders row with status READY and total 300. These table names, fields and status are examples. Use your operation requirements and test database schema.

{"orderId":"ORD-1042","status":"READY","total":300}

Why a successful response is not enough

The response shows what the request handler returned. Matching the submitted JSON does not by itself prove database persistence. Asynchronous processing can finish later. Agree a persistence deadline and read source so replica lag is not mistaken for lost data.

Connect to a PostgreSQL test database

Create a Checkcraft Pro connection to an existing test database using a SELECT-only account supplied by its owner. The address below illustrates a local training database. Replace its host, port and database name. A successful connection test confirms login, not access to the target table. DBeaver is not required.

jdbc:postgresql://localhost:5432/app

Find the record by the API response ID

Save the SELECT below after adapting table and column names. For a standalone check, set the parameter to orderId=ORD-1042. In a scenario, orderId=${orderId} uses the value extracted by the preceding HTTP step. Parameters are passed separately from SQL. Selecting only the newest row can return another operation.

SELECT status, total FROM orders WHERE id = :orderId

Compare request, response and database values

For this example, expect exactly one row and enter the two expected columns below. Mark total as numeric so 300 and 300.00 compare equally. The expected 300 comes from the request requirement. Copying an incorrect 350 from the API response would only confirm agreement between two wrong results.

status=READY
total=300

Wait for asynchronous persistence

If your operation is allowed 10 seconds to persist, an illustrative configuration is a 10000 ms timeout and 500 ms interval. This is not a universal service target. The check repeats SELECT until the expectation matches or time runs out. It does not repeat the creating POST. Attach the saved database check after the HTTP request in a Pro scenario.

Distinguish missing records from wrong values

For zero rows, first check orderId, environment and timeout. For a row with a different status or total, record the expected and actual values. Treat connection and permission failures separately from an absent record. Share the operation ID, service versions and permitted query results with the developer.

Choose a repeatable verification workflow

A one-off SELECT can run in DBeaver; code or AI assistance can help automate it. This Checkcraft Pro workflow keeps the database query, expectations and execution order alongside API checks. Correlated logs can help locate processing failures. It verifies one operation, not an entire warehouse. Compare your test result with an agreed requirement.

Start with the linked example and compare its result with your own test requirement.