API Authentication Types Overview

Authentication controls how AXQA identifies and authorizes an API request when calling a protected endpoint.
An API Definition can store its authentication configuration once and reuse it during direct API testing, Test Case execution, and other supported API workflows.

Why it matters

• Keeps authentication configuration connected to the reusable API Definition.
• Avoids hardcoding credentials inside individual Test Cases.
• Makes authenticated API testing easier to configure and reuse consistently.

When to use it

• When an endpoint requires authentication before accepting a request.
• When different APIs in the same project use different authentication methods.
• When you want saved authentication to be reused automatically during future executions.

Core concepts

• Authentication Type – The authentication method selected for an API Definition.
• API Key – A static key sent using the x-api-key request header.
• Bearer Token – A token sent through the HTTP Authorization header.
• OAuth2 Credentials – Client credentials stored with the API Definition for the supported OAuth2 configuration.
• Stored Credentials – Authentication values saved securely with the API Definition.
• Test Override – A temporary authentication value used during a test without replacing the saved value.

How it works

1. Select the required Authentication Type.
2. AXQA displays the credential fields required for that authentication method.
3. Enter the required credentials.
4. Save the API Definition.
5. AXQA securely stores the authentication values with the API.
6. During execution, AXQA builds the required authentication header automatically.
7. When testing from supported Add or Edit workflows, temporary authentication values can be used without replacing the saved credentials.

How to use it

Step 1: Select an Authentication Type

AXQA currently provides the following authentication options:

• None
• API Key
• Bearer Token
• OAuth2

Choose the option required by the API you are testing.

Step 2: Use None

Choose None when the endpoint does not require authentication.

Example:

Authentication: None
Endpoint: https://api.example.com/public/status

AXQA does not automatically add an authentication header.

You can still define normal Header parameters when the endpoint requires non-authentication headers.

Step 3: Use API Key

Choose API Key when the target API expects a key through the x-api-key header.

Example configuration:

Authentication: API Key
API Key: abc123-example-key
Endpoint: https://api.example.com/orders

AXQA sends:

x-api-key: abc123-example-key

Example request:

GET /orders HTTP/1.1
Host: api.example.com
x-api-key: abc123-example-key

If the selected authentication type is API Key and no key is available, AXQA blocks the test instead of sending the request without the required authentication.

Step 4: Use Bearer Token

Choose Bearer Token when the API expects authorization through the HTTP Authorization header.

Example configuration:

Authentication: Bearer Token
Bearer Token: eyJhbGciOi...

AXQA automatically sends:

Authorization: Bearer eyJhbGciOi...

You do not need to manually add the Bearer prefix when entering a normal token.

For example:

eyJhbGciOi...

becomes:

Authorization: Bearer eyJhbGciOi...

Step 5: Use a preformatted Authorization value

The Bearer Token field also accepts an authorization value that already begins with:

Bearer

or:

Basic

If the prefix is already present, AXQA sends the value without adding another prefix.

For example:

Bearer eyJhbGciOi...

is sent as:

Authorization: Bearer eyJhbGciOi...

A preformatted Basic authorization value such as:

Basic dXNlcjpwYXNzd29yZA==

is sent as:

Authorization: Basic dXNlcjpwYXNzd29yZA==

This allows APIs that require a preformatted Authorization value to use the same protected authentication field.

Step 6: Use OAuth2

Choose OAuth2 when the API Definition uses the supported OAuth2 credential configuration.

AXQA requires:

OAuth2 Client ID
OAuth2 Client Secret

Both values must be configured before the API Definition can be saved with OAuth2 authentication.

The credentials are stored with the API Definition and protected as authentication values.

Always test the API after configuring OAuth2 to confirm that the target service accepts the configured authorization behavior.

Step 7: Test authentication before saving

When creating a new API Definition, use Test This API to confirm the authentication configuration before saving it.

For example:

Endpoint:
https://api.example.com/users

Method:
GET

Authentication:
Bearer Token

Bearer Token:
eyJhbGciOi...

Click Run Test.

If authentication is accepted, the API response is displayed directly in AXQA.

Step 8: Temporarily override saved credentials

When editing and testing an existing API, AXQA can use temporary authentication values for that test.

For example, an API may already have:

Saved Bearer Token:
Production token

During testing you can provide:

Temporary Bearer Token:
Staging token

The temporary value is used for that test execution.

The saved credential remains unchanged unless you explicitly save the new value.

Step 9: Editing saved credentials

When editing an API Definition, AXQA does not display the previously stored credential value inside the credential field.

Leaving the credential field empty keeps the existing saved credential.

Enter a new value only when you want to replace the stored credential.

Best practices

• Store authentication credentials in the dedicated Authentication fields instead of normal Parameters.
• Use API Parameters for request-specific values, not for credentials already supported by AXQA Authentication.
• Use different API Definitions when endpoints genuinely require different authentication configurations.
• Test authentication after changing credentials or Authentication Type.
• Replace credentials when they are rotated by the target system.
• Avoid placing secrets in API descriptions, notes, examples, or normal test data.

Common mistakes

❌ Adding an API Key as a normal Header parameter when the API uses the AXQA API Key authentication option.
✔ Select API Key authentication and store the key in the protected API Key field.

❌ Entering Bearer Bearer <token>.
✔ Enter the token without a prefix, or provide one complete Bearer <token> value.

❌ Leaving required authentication credentials empty.
✔ Configure the required credential fields before saving or testing the API.

❌ Entering temporary test credentials and assuming they automatically replace the stored credentials.
✔ Test overrides are temporary unless the API Definition is explicitly updated and saved.

❌ Storing authentication credentials inside descriptions, schemas, notes, or examples.
✔ Store supported credentials only in the dedicated Authentication fields.

Security & permissions

• API authentication credentials are stored using encrypted model fields.
• Credential fields are treated as protected password-style inputs in the AXQA interface.
• Existing saved credentials are not prefilled when an API Definition is opened for editing.
• Leaving a protected credential field empty during editing preserves the existing stored value.
• Missing required authentication credentials cause supported test executions to be rejected instead of intentionally sending an unauthenticated request.
• Authentication configuration follows the access controls applied to the API Definition and its project.
• Credentials should never be placed in documentation, screenshots, comments, or other non-protected fields.

Related documentation

• API Manager Overview
• Creating a New API Definition
• Editing an API Definition
• API Definitions & Parameters
• API Parameters in Depth
• Body Modes: Parameters vs Raw JSON
• Testing an API
• API Lifecycle & Reuse in Test Cases