Action API vs Expected API

A Test Step can execute an API as an action, validate results against another API, or both. Understanding the difference between Action API and Expected API is essential for building reliable, reusable API-based test cases.

Why it matters

• You want to trigger a backend change (Action API).
• You want to validate system state using another endpoint (Expected API).
• You need to compare two live API responses.
• You want to avoid hardcoding expected JSON.

When to use it

• Action API – the API executed as part of the step’s action.
• Expected API – a second API used to validate the result.
• Expected Literal – a static value used for comparison.
• Comparison Type – defines how actual and expected values are evaluated.

Core concepts

• Project – isolated workspace
• Test Case – single test definition
• Test Plan – group of test cases

How it works

Scenario 1: Action API only

1. The Action API is executed.

2. Its response becomes the “actual result.”

3. The result is validated against:

   • Expected Literal

   • JSON path

   • Entire response

Scenario 2: Expected API only

1. No Action API is executed.
2. The Expected API is called.
3. Its response is validated against expected conditions.

Scenario 3: Action API + Expected API (Most Powerful Mode)

1. The Action API is executed first.
2. The Expected API is executed next.
3. The system compares results between them.

This allows:

• Verifying that an action changed system state.
• Comparing values across two endpoints.
• Validating post-action conditions dynamically.

How to use it

Step 1: Assign the Action API

• Select an API in the API field of the step.
• This API will execute first when the step runs.

Step 2: Define the validation method

Choose one of the following:

• Use Expected Literal
• Use JSON Path + Literal
• Use Expected API

Step 3: Assign the Expected API (if needed)

If validating against another endpoint, select it in the Expected API field.

Step 4: Select Comparison Type

Choose how values should be compared:

• equals – Values must match exactly (e.g., 100 == 100).
• not equals – Values must be different (e.g., status not error).
• contains – Response must include a substring or element.
• exists – Field must be present in the response.
• not exists – Field must not be present.
• is null – Value must be null.
• not null – Value must not be null.
• greater than – Numeric value must be higher than expected.
• less than – Numeric value must be lower than expected.
• regex – Value must match a pattern (e.g., email format).
• range – Numeric value must fall between Min and Max.

Execution order summary

How Comparison Source Is Determined

The system determines the comparison source based on the configuration of the step:

• If an Expected API is defined, its response becomes the expected reference.
• If no Expected API is defined but an Expected Literal is provided, the literal value is used.
• If neither is defined, validation is performed against the Action API response only.

When both Action and Expected APIs are present:

• The Action API response is treated as the actual value.
• The Expected API response is treated as the expected value.

Best practices

• Use Action + Expected API when validating state changes.
• Use Expected API instead of static literals when system values are dynamic.
• Keep validation logic clear and intentional.
• Avoid hardcoding values that may change between environments.

Common mistakes

❌ Mistake 1: Using static expected JSON when the system is dynamic
✔ Fix: Use Expected API for live state comparison.

❌ Mistake 2: Expecting Expected API to run before Action API
✔ Fix: Action API always runs first when both are defined.

❌ Mistake 3: Mixing Expected Literal and Expected API without clarity
✔ Fix: Decide whether validation is static or dynamic.

Security & permissions

• Both Action and Expected APIs follow project access controls.
• Authentication remains defined at the API Definition level.
• Execution behavior depends on the selected execution source.

Related documentation

• Test Steps Fundamentals
• API Lifecycle & Reuse
• API Tree (Response Tree)
• Comparison Logic Overview