Authentication defines how an API request proves its identity when calling an endpoint. AXQA supports multiple authentication types to match common API patterns, while keeping credentials managed centrally and reused safely across executions.
Why it matters
- Correct access: Many APIs reject requests without proper authentication.
- Consistency: Authentication is defined once and reused across tests.
- Reduced errors: Teams avoid duplicating or misconfiguring credentials in multiple places.
When to use it
- The API requires credentials to be accessed.
- Different APIs within the same project use different authentication methods.
- You want to test authenticated endpoints without hardcoding values in test logic.
Core concepts
- Authentication Type – the method used to authorize a request.
- Credential Fields – values associated with the selected authentication type.
- Stored Credentials – authentication values saved with the API Definition.
- Test Override – temporary credentials used only during testing.
How it works
- You select an authentication type for the API Definition.
- AXQA shows only the fields relevant to that type.
- Credentials are stored with the definition and reused automatically.
- During testing, credentials may be temporarily overridden if needed.
How to use it
Step 1: Select an authentication type
On the API Definition page, choose one of the available authentication options. The interface updates automatically to match your selection.
Step 2: None
Choose None when:
- The API is public.
- No credentials are required to access the endpoint.
Note
No authentication data is sent with the request.
Step 3: API Key
Use API Key when the API expects a static key value:
- The key is included automatically when the request runs.
- The exact placement is handled by the system based on the API Definition.
Warning
This option is commonly used for internal or partner APIs.
Step 4: Bearer Token
Use Bearer Token when the API requires token-based authorization:
- The token is attached to the request automatically.
- The value may represent different token formats depending on the API.
Note
This is a common choice for modern REST APIs.
Step 5: OAuth2
Use OAuth2 when the API relies on a client-based authorization flow:
- You provide the required client identifiers through the interface.
- AXQA manages how these values are applied during execution.
Note
This option is typically used for enterprise or third-party platforms.
Step 6: Testing with authentication
When running a test:
- Stored credentials are used by default.
- You may temporarily enter different values to test variations.
- Test overrides do not replace saved credentials unless explicitly updated.
Best practices
- Choose the simplest authentication type that satisfies the API requirements.
- Keep authentication consistent across related APIs within a project.
- Avoid switching authentication types unless the API contract has changed.
- Always test the API after changing authentication settings.
Common mistakes
❌ Mistake 1: Selecting an authentication type but leaving required fields empty
✔ Fix: Ensure all required fields for the selected type are filled before testing.
❌ Mistake 2: Overwriting stored credentials unintentionally during testing
✔ Fix: Use temporary test values only when needed, and save changes intentionally.
Security & permissions
- Authentication values are handled securely through the system interface.
- Credentials are not exposed in responses or logs shown to users.
- Only authorized users can create or modify authentication settings.
Related documentation
- Creating a New API Definition
- Editing an API Definition
- Testing an API
- Using API Definitions in Test Cases