Testing an API allows you to validate an endpoint’s behavior before and after it is used in test cases. AXQA provides multiple ways to run an API test so you can verify correctness, parameters, and responses at every stage.
Why it matters
- Early validation: Catch issues before APIs are reused in test cases.
- Faster iteration: Test directly from the UI without creating extra tests.
- Confidence: Ensure APIs behave as expected when parameters or authentication change.
When to use it
- You are creating a new API Definition and want to validate it immediately.
- You updated an existing API and need to confirm it still works.
- You want to experiment with different parameter values or payloads.
Core concepts
- Test Execution – a single run of an API request.
- Test Inputs – values provided for parameters during execution.
- Inline Testing – testing directly from the API edit page.
- Pre-Save Testing – testing an API before it is saved.
How it works
- You select where to test the API (Add page, Edit page, or Standalone view).
- You provide parameter values and optional overrides.
- AXQA executes the request using the current definition.
- The response is displayed immediately for review.
How to use it
Step 1: Testing from the “Add new API” page
- Fill in the API Definition fields.
- Scroll to Test This API at the bottom.
- Enter values for parameters.
- Click Run Test.
Note
This lets you validate the API before saving it.
Step 2: Inline testing from the “Edit API” page
- Open an existing API Definition.
- Scroll to Test This API.
- Provide parameter values or temporary overrides.
- Click Run Test to execute immediately.
Warning
Inline tests do not modify the saved API unless you explicitly save changes.
Step 3: Testing from the standalone API test view
- Open an API Definition and choose Test API.
- Run the API using the saved configuration.
- Review the response output.
Note
This mode is useful for quick validation without editing the API.
Step 4: Working with parameters during testing
- Body parameters automatically generate input fields (Parameters mode).
- Defaults are used when inputs are left empty.
- Path and Query parameters must match the endpoint structure.
Step 5: Interpreting the response
After execution, the response includes:
- Status information
- Execution time
- Response content
Note
Responses are shown in a readable format and can be copied for reference.
Step 6: Retesting after changes
Whenever you update:
- Parameters
- Authentication
- Body Mode
Note
Run the test again to confirm behavior before reuse.
Best practices
- Always test an API at least once before using it in a test case.
- Retest after any structural change.
- Start with minimal parameters, then expand.
- Use testing to validate assumptions, not just success responses.
Common mistakes
❌ Mistake 1: Testing without required parameter values
✔ Fix: Ensure all required parameters are provided before running the test.
❌ Mistake 2: Forgetting to retest after editing an API
✔ Fix: Make testing part of every API update workflow.
Security & permissions
- Test execution follows project access rules.
- Sensitive data is not exposed in the test output.
- Only authorized users can execute API tests.
Related documentation
- Creating a New API Definition
- Editing an API Definition
- Parameters in Depth
- API Lifecycle & Reuse in Test Cases