Setting Assertions and Conditions

We make it simple to monitor API behavior and catch issues fast using conditions and assertions. This guide explains what both are, how to use them, and includes practical examples for all experience levels.

What are Conditions & Assertions?

• Conditions: Rules that decide what happens after an API endpoint is called (for example, only run the next step if the previous response was successful).
• Assertions: Checks that automatically verify part or all of your API response—like the status code, headers, or even the full response body—match what you expect.

How to Set Up Conditions & Assertions

1. Edit Your API Call

   • Go to the API call you want to add checks to.
   • Click on the "Conditions" (or "Assertions") tab.

2. Add a Condition/Assertion

   • Click Add Condition or Add Assertion.
   • Choose what you want to check: status code, header, response body, _raw response, or response size.

3. Define What to Match

   • Pick a check type (equals, contains, less than, etc).
   • Enter what you expect to see (a number, keyword, or value).

4. Save & Test

   • Save your API call settings.
   • Test the call to make sure your assertions behave as intended.

---

Common & Advanced Scenarios

---

_raw Path & Response Size: Best Practices

• The _raw path lets you check the entire, raw response exactly as received—great for custom formats, binary data, or advanced cases.
  • Example: Check if the raw response is empty:
    JSON

    {
      "assert": {"path": "_raw", "equals": ""}
    }
    

  • Example: Look for a keyword in the response:
    JSON

    {
      "assert": {"path": "_raw", "contains": "success"}
    }
    

• Response Size (bytes) helps catch empty or unexpectedly large responses regardless of how they're formatted.
  • Example: Assert the response is empty (0 bytes):
    JSON

    {
      "assert": {"path": "Response Size (bytes)", "equals": 0}
    }
    

  • Example: Ensure response is not too big:
    JSON

    {
      "assert": {"path": "Response Size (bytes)", "lessThan": 100}
    }
    

---

Example Scenario: Override default HTTP codes

📘

Scenario

You want to validate that a call cannot succeed from a particular geography or a call with an OAuth scope of a particular kind always fails. In these scenario, the expected behavior should fail, and a Pass indicuates a conformance problem.

For this example, let's override the default settings to set a HTTP 500 code as a pass and, therefore, a 200 code becomes a fail. Here are the relevant settings:

Check a Response Body for a Specific String

You can examine the returned response body for a variable. For instance, if you are expecting the response body to have an access token, you can set a condition for the API call to return an error if there is none.

Set an Alert based on a timing issue

You can set an alert depending on the length of the call or a component of the call. For instance, you can set the response type to Passed but slow if the Total Latency is greater than 1000 ms.

Recommendations & Tips

• Start with simple assertions (status codes, headers), then add deeper content checks as your needs grow.
• Use the _raw path for non-standard responses or when you need total control over matching.
• Add response size checks as a safety net against payload changes or API errors.
• Update assertions as your API evolves.
• Check test results regularly and adjust your checks for new endpoints or behaviors.