HTTP headers are the key-value pairs attached to every HTTP request and response that carry information about the request itself — separate from the actual content being sent — such as who's asking, what format they expect the data in, and how the data should be handled. In feed management, headers are what let a feed platform authenticate itself to an API, specify that it's sending or expecting JSON rather than XML, and pass along caching or compression instructions, all without any of that information cluttering the actual product data in the request body.

Why It Matters for Feed Management

Every automated connection between a feed platform and a channel — Google Merchant Center, Meta Catalog, a retailer's own ERP — depends on headers doing their job correctly. An Authorization header carrying an invalid or expired token will cause an otherwise perfectly formatted feed submission to fail outright, and a missing or incorrect Content-Type header can cause a channel to misinterpret a JSON payload as plain text, or vice versa, silently corrupting an upload. Headers are also where rate-limiting and retry logic live: many APIs return headers like Retry-After or X-RateLimit-Remaining to tell a feed platform how many more requests it can make before being throttled, which matters when syncing tens of thousands of SKUs against a channel that caps requests per minute. Debugging a failed feed sync often comes down to inspecting headers first, since the body of a request can look perfectly correct while a header is quietly causing the rejection.

How It Works

Headers are sent as plain text lines at the top of an HTTP request or response, separate from the URL and the body. A typical feed API request might include Authorization: Bearer <token> to prove the caller's identity, Content-Type: application/json to declare the format of the data being sent, and Accept: application/json to specify the format expected back. Unlike a query parameter or the other URL parameters that appear directly in the address bar, headers are invisible in the URL itself, which makes them the right place for sensitive information like authentication tokens that shouldn't show up in browser history or server logs. Some headers are set automatically by the client or server (like Date or Content-Length), while others — particularly authentication and custom tracking headers — are configured explicitly by whoever builds the integration.

Example

<!-- Representative HTTP request headers sent when a feed platform
     pushes a product update to a channel's API -->
<item>
  <g:id>SKU-40217</g:id>
  <title>Ceramic Plant Pot - 8 inch, Terracotta</title>
  <g:price>18.50 USD</g:price>
  <sync_request_headers>
    Authorization: Bearer eyJhbGciOi...
    Content-Type: application/json
    Accept: application/json
  </sync_request_headers>
</item>

The sync_request_headers block above isn't a real feed attribute, but it illustrates the header metadata that accompanies this item's data every time it's pushed to a channel through an API call rather than a bulk file upload.

Related Concepts

Headers work alongside — but separately from — the query parameters and URL parameters that also travel with a request, with the key difference being visibility: headers stay out of the URL, which is why authentication tokens live there instead of appended to a link. Together, all three define what a channel's API actually receives, and getting any one of them wrong is one of the most common causes of a feed sync silently failing.