Assertions and Validations

So far, we've built test scenarios that send requests and pass data. But how do we know if the API is actually working correctly? A request might return 200 OK but send back empty data, or worst, wrong data.

Assertions are the checkpoints of your testing. They automatically verify that the API response matches your expectations. In this chapter, we'll master both standard response assertions and powerful database validations.

What are Assertions?

An assertion is simply a statement that must be true for your test to pass. Without assertions, your test essentially says, "I sent a request, and the server replied." It confirms communication but not correctness.

With assertions, your test becomes specific: "I sent a request, and I expect the status code to be 201, and the returned user ID to be a number." If this expectation isn't met, the test fails immediately, alerting you to the problem.

Why Use Assertions?

You might think, "I can just look at the response and see if it's correct." For a single manual test, sure, you can eyeballing the JSON and say, "Yup, looks good."

But automated testing is blind. The computer needs explicit instructions—assertions—to judge pass or fail. This becomes critical during Regression Testing. If you deploy a new version weekly, you need a safety net that instantly validates hundreds of test cases. You can't manually check historical responses every time; assertions do that for you.

Adding Your First Assertion

Apidog makes adding assertions incredibly easy—no coding required for most common cases.

Method: The "Post-processors" Tab

Open your request (e.g., POST /users).

Go to the Post-processors tab.

Click Add Post-processor -> Assertion.

Select Assertion Target

You can check almost anything: Status code, Headers, JSON Body, etc.

You'll see a detailed form for configuring your assertion rule:

Name: Give your assertion a clear name (e.g., "Verify User ID").

Target Object: Choose where the data comes from (usually Response JSON or Response Header).

JSONPath Expression: The specific field you want to check (e.g., $.data.id).

Assertion: The rule to apply (e.g., Equals, Is Not Null) and the expected value.

Common Assertion Patterns

Here are the most common things you should check:

Status Code: The first line of defense.

Response.status.code Equals 200 (Success)

Response.status.code Equals 404 (Not Found)

Response Time: Ensure performance.

Response.time Less than 500 (ms)

JSON Body Values: Verify specific data.

$.email Equals test@example.com

$.id Exists (Not null)

Header Values: Check content type or auth headers.

Response.header.Content-Type Contains application/json

See details Assertions

Pro Tip: You can also add assertions directly from the APIs > Request tab by clicking on the response field!

Automatic Response Validation

Tired of checking every field manually? Apidog has a built-in feature called Response Validation that does the heavy lifting for you.

When enabled, Apidog compares the actual API response against the Response Definition (Schema) you defined in your API documentation.

In your request settings, look for the Response Validation toggle.

If the API returns a string where a number is expected, or misses a required field, the test will automatically fail.

This ensures your implementation stays strictly in sync with your API design contract.

Real Case: Validating User Registration

Let's verify our POST /users endpoint from the previous chapter. When we create a user, we expect a very specific outcome.

Our Expectations:

Status must be 201 Created (or 200).

Response must contain the new id.

Response must contain the same email we sent.

Response must NOT contain the password (security check).

Configuration in Apidog:

Subject	Comparator	Value	Description
`Response.status.code`	Equals	`201`	Verify creation success
`$.id`	Exist	(Empty)	Verify ID is returned
`$.email`	Equals	`{{newUserName}}`	Verify email matches input
`$.password`	Is Null	(Empty)	Verify password is hidden

Once configured, run the request. If even one of these conditions is not met, Apidog will flag the test as failed.

Validating with Database Operations

Response assertions are great, but they only tell you what the API says it did. Did the data actually arrive in the database?

Database Operations allow you to connect directly to your SQL database within a test step to verify the "ground truth."

Why you need this

Data Integrity: The API says "User Created," but is the record actually in the users table?

State Validation: After a status update (e.g., "Order Paid"), is the database column updated correctly?

Data Cleanup: Delete test data after the test finishes.

How to use Database Operations

Configure Connection: Go to Settings -> Database Connections and add your MySQL/PostgreSQL/Oracle details.

Add Post-processor: In your request, add Database Operation.

Fill in the form:

Operation Name: e.g., "Verify User Created".

Database Connections: Select your pre-configured connection.

SQL Command: Enter your query. You can use variables!

Extract Result To Variable: Map the query result to a variable for future assertions.

Variable: db_user_id

JSONPath Expression: $[0].id (Extracts 'id' from the first row)

Assert: Now you can add an assertion step to check if {{db_user_id}} matches the API response id.

See details: Database Operations

Advanced: Scripting with `pm.dataSource`

For complex validation, you can use scripts to query and assert in one go.

Best Practices

Assert Everything: Every test step should have at least a status code assertion.

Be Specific: Don't just check 200 OK. Check that the id is a number and the status is "active".

Negative Testing: Create test cases that expect failure. E.g., send an invalid email and assert that the status code is 400 and the error message contains "Invalid email".

Database Cleanliness: Use DB operations to DELETE the user created during testing at the end of your workflow (Teardown).

Key Takeaways

Assertions are mandatory for reliable automation; without them, tests are blind.

Use Visual Assertions for 90% of your needs (status, body, headers).

Use Database Operations to verify data integrity and truly validate system state.

Combine API response checks with Database checks for Full-Stack QA.

What's Next

We can now run a scenario and verify it works. But what if we need to run a test 100 times with different names? Or skip a step based on a condition?

In the next chapter, we'll introduce Flow Control and Looping to build logic into your tests.

Continue with → Flow Control: If, For, ForEach

Assertions and Validations

What are Assertions?#

Why Use Assertions?#

Adding Your First Assertion#

Method: The "Post-processors" Tab#

Select Assertion Target#

Common Assertion Patterns#

Automatic Response Validation#

Real Case: Validating User Registration#

Validating with Database Operations#

Why you need this#

How to use Database Operations#

Advanced: Scripting with pm.dataSource#

Best Practices#

Key Takeaways#

What's Next#