Using Multiple Authentication Requirements in One API Request

Some enterprise APIs require more than one authentication or identification value in the same request.
For example, an endpoint may require a Bearer Token together with an API key, client identifier, or authenticated session cookie.

Why it matters

• Supports APIs that require layered authentication.
• Avoids hardcoding authentication-related values directly inside Test Cases.
• Keeps reusable API security configuration centralized.
• Allows AXQA to test more complex enterprise API gateways.

When to use it

• When an API requires a Bearer Token and an additional API key.
• When authentication combines a token with a client-specific header.
• When an API requires an authentication token together with a session cookie.
• When an API gateway requires additional Query or Header values before accepting the request.

Core concepts

• Primary Authentication – The Authentication Type configured directly on the API Definition.
• Bearer Token – Sent through the Authorization header.
• API Key – Can be configured through the supported API authentication option or, where required as an additional value, through an API Header parameter.
• Header Parameter – An additional request header sent with the API call.
• Cookie Parameter – A cookie included with the request.
• Query Parameter – A value appended to the request URL.

How it works

1. Configure the API's primary Authentication Type.
2. Add any additional authentication requirements as API Parameters.
3. Select the correct parameter location.
4. AXQA builds the final request.
5. The primary authentication and additional parameters are sent together.
6. The target API validates all required authentication information.

How to use it

Step 1: Example requirement

Assume an API requires all three of these values:

The request should be:

Step 2: Configure the primary authentication

Create or edit the API Definition.

Configure:

AXQA uses the Bearer Token as the primary authentication mechanism.

Step 3: Add the additional API key

Add an API Parameter:

This creates the additional request header:

Step 4: Add the session cookie

Add another parameter:

AXQA sends:

Step 5: Execute the API

When AXQA executes the request, the final authentication context contains:

All required values are sent as part of the same request.

Step 6: Override values during testing

When supported by the execution flow, provide runtime values instead of permanently changing the API Definition.

For example:

This lets the same API Definition support different test data without duplicating the complete API.

Best practices

• Use the dedicated Authentication field for the primary supported authentication mechanism.
• Use Parameters only for additional authentication values required by the target API.
• Mark required authentication parameters as Required.
• Use controlled test credentials instead of production credentials whenever possible.
•  Keep authentication values out of Test Case descriptions and comments.

Common mistakes

❌ Trying to select multiple primary Authentication Types at the same time.
✔ Configure one primary Authentication Type and add additional required values through supported Header, Cookie, or Query parameters.

❌ Putting an API key inside the request body when the target API expects a header.
✔ Match the parameter location required by the API contract.

❌ Recreating the complete API for every authentication value.
✔ Reuse one API Definition and override supported parameter values when required.

Security & permissions

• Authentication credentials should remain in dedicated protected fields whenever AXQA provides one.
• Do not place secrets in API descriptions or Test Case notes.
• Additional parameters are sent only to the configured API target.
• Server-side execution continues to apply outbound URL security controls.
• Smart Agent execution remains subject to its project Network Allowlist.

Related documentation

• API Authentication Types & Examples
• API Parameters in Depth
• Reusing Login APIs Across Test Cases Without Duplication
• Testing an API
• Credential & Sensitive Data Protection