Set custom HTTP headers inside your automated tests
Sometimes your application or API behaves differently depending on how requests are presented. Security tokens, feature flags, authentication contexts, locale settings, or custom platforms may all depend on specific headers being sent with HTTP requests.
The Set Headers step gives your test precise control over HTTP headers used during a run. This lets you shape request behaviour at the network level without changing your application code or backend configuration.
By controlling headers directly inside your flow, you ensure your automation is exercising the same conditions real users or systems would experience.
Why setting headers is useful
Many applications use headers to influence:
Authorization and access control
API versioning
Feature flag toggles
Language preferences
A/B test allocations
Security policies
Request routing
Without the ability to set HTTP headers, automation might only hit default behaviour, missing critical permutations that occur in real usage.
With this step, you can simulate:
Logged-in vs guest requests
Region-specific content delivery
API version transitions
Feature rollouts based on custom flags
This gives you broader, more accurate coverage.
How headers influence test behaviour
When your test runs in a browser or API context, the requests it generates may include default headers that are standard across browsers and clients. But custom headers allow you to:
Include tokens or session identifiers
Insert trace headers for debugging
Set locale or content type preferences
Enable or disable feature flags
Trigger different backend logic paths
Because Set Headers applies to network requests initiated after the step, your automation can adapt dynamically based on the needs of the flow.
Work with APIs and backend tests
Headers are essential when your test interacts with APIs or application routes that require specific context. For example:
Calling a REST endpoint with an API key
Passing a custom trace ID
Presenting a region code for localized content
Providing a session token for authentication
Using the step to set headers ensures that these API calls reflect the same conditions as real system interactions.
This makes your tests more robust and less brittle when systems expect particular metadata.
Integrate with dynamic values and stored data
Headers often need to carry values that are generated earlier in the flow, such as:
Session IDs
Access tokens
Stored variables
Dynamic values like timestamps
Because DoesQA lets you access stored and dynamic values, you can compose headers with precision. For example:
Generate a token earlier
Store it
Use it as a header for subsequent requests
This allows your test to remain fully automated and context aware.
Broader use cases and flexibility
The Set Headers capability is valuable in situations where:
Your system gates behaviour based on headers
You need to validate multiple backend routes
You want to simulate specific client conditions
You are testing internationalization scenarios
You need to assert correct header usage in API responses
Because headers can shape how your application behaves, testing them directly gives you deeper confidence that your software works under real conditions.
When headers matter, automation should test them explicitly. Using this step gives you fine-grained control over request context without the need for custom plugins or external tooling.