Practical tutorial: how to create API tests in Apidog with a Design-First approach (step by step)

Note: This tutorial uses the Pet Store sample API included in Apidog and blurred APIs from real cases. No real or sensitive information is exposed. Everything shown here applies directly to real business APIs.

0. Tutorial goal

By the end of this tutorial, you will be able to:

• Design an endpoint in Apidog using Design-First Mode
• Run an Endpoint Compliance Check using AI
• Create happy, negative, and edge test cases
• Use dynamic test data
• Validate responses with Post-Processors
• Validate data directly against the database
• Use JavaScript to validate implicit business logic

This tutorial is intended for QAs, senior QAs, and developers who want to test APIs with a quality mindset, not just execute requests.

1. Step 1: create or select the endpoint (Design-First)

In Apidog, open your project and make sure you are working in Design-First Mode.

We will use the sample endpoint:

POST /pet — Add a new pet to the store

What to check on this screen

1. Correct HTTP method (POST)
2. Clearly defined path
3. Body parameters marked as required or optional
4. Visible request examples
5. Documented responses (for example: 201, 400)

Image 1 — main endpoint definition in Apidog, including method, path, and request body

👉 At this point, it does not matter whether the backend has been implemented yet.

2. Step 2: clearly define the API contract

Before testing anything, make sure the contract is clear.

For POST /pet, verify:

• name → string, required
• status → string, required

In the Responses section, ensure you have:

• 201 for successful creation
• Error codes for failure creation
• A documented response structure (id, name, category, error codes, log messages, etc.)

This is what frontend and QA will rely on later.

3. Step 3: run the Endpoint Compliance Check

From the endpoint menu, run Endpoint Compliance Check.

What Apidog validates here

• Consistent field naming
• Correct data types
• Properly defined responses
• Missing documentation

Endpoint Compliance Check button is located in the upper-right area of the endpoint view

👉 If errors appear here, do not continue. Fix the design first.

4. Step 4: go to the Test Cases tab

Now open the Test Cases tab for the endpoint.

This is where QA work truly begins.

This view lists all test cases associated with the endpoint, typically grouped by positive, negative, and edge scenarios

Create your first test cases:

Happy path

• Name: Create pet successfully
• Input: valid name + valid status
• Expected result: 201

Negative case

• Name: Create pet without name
• Input: empty name
• Expected result: 400

Edge case

• Name: Create pet with very long name
• Input: long string
• Expected result: controlled error

5. Step 5: use dynamic data

To avoid hardcoded data, use dynamic variables.

Example for name:

Pet-QA-{{$number.int(min=1,max=9999)}}

This allows the test to be executed multiple times without conflicts.

6. Step 6: prepare data from the database (optional but recommended)

If your environment allows it, add a Database Operation.

Example use case:

1. Run a query to retrieve an inactive category
2. Use that ID as request input
3. Execute the test

Expected result:

• 400
• Business-specific error code

7. Step 7: validate the response with Post-Processors

After executing the request, add validations:

Validation 1: HTTP Status

• Expected: 201
• Creation in the database
• Slug created

Validation 2: internal error code

• JSONPath: $.code
• Expected value: defined business error code

In the Post-Processors section you can configure assertions, extractions, and database validations in just a few clicks

These validations can be configured in two clicks.

8. Step 8: validate against the database

For a successful scenario:

1. Extract the id from the response
2. Run a database query
3. Validate that:

• The record exists
• The status is correct
• It meets business expectations

Even when testing only APIs, this becomes true end-to-end testing.

9. Step 9: use JavaScript to validate implicit logic

Many systems apply automatic logic.

Example:

• You send name = "Pet QA ladder 12345"
• The system generates slug = pet-qa-ladder-12345

QA can:

1. Transform the sent name into a slug using JavaScript
2. Compare it with the value stored in the database or returned by the API

This validates implicit business behavior that is often undocumented.

10. Step 10: repeat the flow for more scenarios

Repeat steps 4 to 9 for:

• Negative scenarios
• Edge cases
• Business-specific rules

Each new test case reuses the same design and structure.

11. Final checklist: is your endpoint really tested?

Before considering an endpoint fully tested, review this checklist:

Design and contract

• The endpoint was designed before development
• Required and optional fields are clearly defined
• Request and response examples exist
• Expected HTTP status codes are documented

Compliance and governance

• The endpoint passed the Endpoint Compliance Check
• No naming inconsistencies exist
• Data types are clear and consistent

Test coverage

• Happy path cases exist
• Negative cases exist
• Edge cases exist

Data and validations

• Dynamic data is used (not hardcoded)
• Business error codes are validated
• Database state is validated

Implicit logic

• Automatic rules are validated (slugs, defaults, states)
• Scripts are used when business logic requires it

If you can check everything, your API does not just work: it is well designed and well tested.

12. Final thoughts

This tutorial is not about learning a tool. It is about learning a way of working.

When QA participates from the design phase:

• Risks are reduced
• Delivery is faster
• Product quality improves

Testing APIs properly is not about running requests.

It is about designing quality from the start.