Using CONTENT_TYPE to split HTTP traffic by format
Radar groups response content types into broad categories rather than leaving you with a mess of MIME types. JSON, XML, video, fonts, binary payloads, serialisation formats and a long tail of oddities all get folded into categories that are easier to read at a glance.
That helps when traffic is noisy. A site can look like it serves “web” traffic until the response mix shows a steady stream of application/json, application/xml, text/xml and other machine-readable formats. From there, the chart stops being decorative and starts hinting at what the application is actually doing.
How Radar turns response types into traffic slices
The content type chart can be filtered by human traffic, bot traffic, or all traffic. That matters more than it sounds because bot-heavy and human-heavy traffic often behave very differently once response format is part of the picture.
Radar also applies the same content type category filter to the Bot vs. Human chart. That gives a second way to read the same stream: one view by actor, another by format. If bot traffic is heavy on JSON or XML, the split will show it. If humans are mostly landing on HTML while bots hammer endpoints, the difference becomes obvious instead of implied.
Where JSON, XML, and the long tail end up in the chart
JSON sits in its own bucket, covering application/json and patterns such as *+json. XML gets grouped too, including text/xml, application/xml, application/rss+xml and application/atom+xml. That is handy because plenty of APIs and feed-style endpoints still answer in XML, even if JSON gets more attention.
The rest is less clean. Video, fonts, binary payloads and serialisation formats all have their own buckets, but anything outside the defined set falls into Other. That is the usual fate of charts that try to stay readable without pretending the internet is neat.
Pulling CONTENTTYPE and APITRAFFIC from the HTTP endpoints
Radar exposes the same dimensions through the HTTP summary, timeseries groups and timeseries endpoints. CONTENTTYPE and contentType are available across summary, timeseries groups and timeseries. APITRAFFIC and apiTraffic are available on summary and timeseries groups, with apiTraffic filters set to API or NON_API for raw request counts.
Summary and timeseries group queries
The summary and grouped timeseries endpoints are the useful ones if the aim is to compare formats or isolate API-related traffic across a time window. CONTENTTYPE gives the format slice, while APITRAFFIC marks whether the request falls into the API bucket or not. That makes the charting layer and the API layer line up instead of drifting apart.
The apiTraffic filter also cuts the counts directly. That is useful when you do not want a pretty ratio and just need the raw volume behind it. Ratios hide a lot of boring detail. Counts do not.
Filtering out cacheable traffic and the non-API remainder
API traffic is not a blanket label for every request that smells like an API. Radar treats API traffic as dynamic, non-cacheable HTTP requests that returned HTTP 200 with JSON or XML response content types. That means cacheable traffic stays out, and so do responses that miss the 200 status code.
That boundary is doing real work. Static assets can sit next to API calls in the same service, but they are not the same thing and should not be counted as such. The non-API remainder is useful too, because it shows the traffic that did not fit the API pattern instead of pretending everything with a machine-readable response is an API.
Reading the result without lying to yourself
The chart is a proxy, not a verdict. It is useful because it narrows the question to a specific traffic shape, but it still depends on content type, status code and cache behaviour. Anything that falls outside JSON or XML stays outside the API bucket, which is fine until someone points at a weird endpoint and asks why it vanished from the line.
Human versus bot splits on the same data
Bot traffic and human traffic can tell very different stories from the same endpoint set. Bots often lean hard on machine-readable responses, while human traffic is usually mixed with HTML pages, static assets and the usual browser mess. Splitting the data by actor stops one group from hiding the other.
That matters when the traffic share looks odd. A spike in application/json may be a product change, a crawler, or a bot loop gone wrong. Without the human and bot split, it is easy to read the chart as “API usage rose” when what actually rose was automation.
What the 200-only rule misses when you check the counts
The 200-only rule is tidy, but it leaves gaps. Any API-like request that returns a non-200 status code drops out of the API traffic bucket, even if the response format is JSON or XML. Cacheable API traffic also stays out, which keeps the count honest for dynamic traffic but lowers the total.
That is the trade-off. The API traffic share is better for watching dynamic request behaviour than for counting every request that hits an API route. If the goal is to compare changing request patterns, it works well enough. If the goal is total API volume across every status code and caching path, the chart is already telling you no.
