Headers are the metadata of your response. They tell you what format the data is in, how long you can cache it, what server sent it, and security settings. Most testers skip header checks. Don't be most testers.
The most important header to test. If your API returns JSON but the Content-Type says text/html — some clients will refuse to parse it. Bugs like this are invisible until they hit production.
// Exact match
pm.test("Content-Type is application/json", function () {
pm.response.to.have.header("Content-Type", "application/json; charset=utf-8");
});
// Partial match using pm.expect (more flexible)
pm.test("Content-Type contains json", function () {
const contentType = pm.response.headers.get("Content-Type");
pm.expect(contentType).to.include("json");
});// Check if a specific header exists
pm.test("X-Request-Id header exists", function () {
pm.response.to.have.header("X-Request-Id");
});
// Check Cache-Control
pm.test("Response is cacheable", function () {
const cacheControl = pm.response.headers.get("Cache-Control");
pm.expect(cacheControl).to.include("max-age");
});
// Check CORS header
pm.test("CORS allows all origins", function () {
pm.response.to.have.header("Access-Control-Allow-Origin", "*");
});
// Check custom header from your API
pm.test("API version header is present", function () {
pm.response.to.have.header("X-API-Version");
const version = pm.response.headers.get("X-API-Version");
pm.expect(version).to.eql("2.1");
});| Header | Why Test It | Common Values |
|---|---|---|
| Content-Type | Ensures client can parse the body | application/json, text/html, text/xml |
| Cache-Control | Prevents stale data issues | no-cache, max-age=3600, private |
| X-Request-Id | Needed for debugging in production | UUID like 550e8400-e29b-41d4... |
| Access-Control-Allow-Origin | CORS — without it, browsers block requests | *, https://yoursite.com |
| Set-Cookie | Auth cookies must have Secure and HttpOnly flags | session=abc; Secure; HttpOnly |
Slow APIs kill user experience. If your login endpoint takes 3 seconds, users will leave. Response time assertions catch performance regressions before users complain.
// Response time under 500ms
pm.test("Response time is under 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});
// Response time within a range
pm.test("Response time is between 100ms and 1000ms", function () {
pm.expect(pm.response.responseTime).to.be.within(100, 1000);
});
// For critical endpoints — strict threshold
pm.test("Login response is under 200ms", function () {
pm.expect(pm.response.responseTime).to.be.below(200);
});Response time in Postman includes network latency. The same API might respond in 50ms locally but 300ms from Postman because of network overhead. Set realistic thresholds — 500ms is a safe default for most APIs. Don't set 50ms and wonder why it always fails.
For performance-critical APIs (payments, search, login), add response time checks with strict thresholds. For batch/reporting endpoints that process lots of data, use lenient thresholds (2-5 seconds). Context matters.
Q: What response headers do you typically validate in API testing?
A: I always check Content-Type to ensure the response format matches what the client expects — usually application/json. For security, I verify CORS headers (Access-Control-Allow-Origin), cookie flags (Secure, HttpOnly), and security headers like X-Content-Type-Options. I also check Cache-Control for caching behavior and X-Request-Id for traceability. For performance, I validate response time using pm.expect(pm.response.responseTime).to.be.below(500).
Key Point: Don't just test the body. Test Content-Type, CORS headers, security headers, and response time. Headers reveal bugs that body checks miss.