API Parameters in Depth

Parameters define how data is passed into an API request. Each parameter represents a single input and specifies where the value belongs, how it behaves, and whether it is required for execution.

Why it matters

Precision: Parameters ensure values are injected into the correct part of the request.
Flexibility: The same API Definition can be reused with different inputs across tests.
Reliability: Clear parameter rules prevent malformed requests and false test failures.

When to use it

You need to pass dynamic values into an API request.
The endpoint includes path placeholders or optional query values.
Headers, cookies, or request bodies vary between executions.

Core concepts

Parameter Name – the identifier used across the definition and test execution.
Location (In) – where the parameter is placed in the request.
Required Flag – indicates whether the request can run without this parameter.
Type – the expected data shape of the value.
Default Value – an optional saved value used when no runtime or test value is provided.

How it works

Parameters are defined as part of an API Definition.
Each parameter is mapped to a specific request location.
During execution, AXQA injects parameter values into the request.
If a value is not provided, defaults (when defined) may be used.

How to use it

Step 1: Define a parameter name

Use clear, meaningful names that match the API contract.
Parameter names are case-insensitive within the same API Definition.

Step 2: Choose the parameter location

Query: Appended to the URL as query string values.
Path: Replaces placeholders in the endpoint (e.g. /users/{id}).
Header: Sent as HTTP headers with the request.
Cookie: Included as cookies when the request is executed.
Body: Included in the request payload (Parameters mode only).

Step 4: Select the parameter type

Choose the type that best represents the expected value:

String – text-based values
Integer – numeric values
Boolean – true / false
Array – multiple values
Object – structured data

Note

The type documents the expected data shape and helps users provide the correct input during testing.

Step 5: Use default values

A saved Default Value can be defined for Query, Path, Header, Cookie, or Body parameters.
If no runtime or test value is provided, AXQA uses the saved Default Value.
In Raw JSON mode, defaults for Body parameters are ignored because Body parameters are not used. Defaults for Query, Path, Header, and Cookie parameters continue to work.

Step 6: Understand multi-value (Array) parameters

When a parameter is defined as an Array, AXQA may execute the request multiple times, once per value, depending on how the API is used in testing.
This is useful for batch validation or testing multiple inputs against the same endpoint.

Best practices

Keep parameter names aligned with the backend API specification.
Use Path parameters explicitly for all endpoint placeholders.
Avoid mixing Raw JSON body mode with Body parameters.
Use Array parameters intentionally and document their purpose.

Common mistakes

❌ Mistake 1: Defining a Path parameter that does not exist in the endpoint
✔ Fix: Ensure every Path parameter matches a placeholder in the URL.

❌ Mistake 2: Expecting Body defaults to apply in Raw JSON mode
✔ Fix: Switch back to Parameters mode if defaults are required.

Security & permissions

Parameters follow project-level access rules.
Sensitive values passed as parameters are handled securely during execution.
Parameter definitions control structure, not exposure of underlying data.

AXQA

Did You Know?