Spring RestTemplate and WebClient user agents
RestTemplate and WebClient are HTTP clients in the Spring framework for Java. Their default user agent reflects whatever underlying HTTP library they use, so it often appears as a generic Java or library token rather than a browser. Recognising these defaults helps you attribute server-side Java traffic from Spring applications.
What this means
Spring is a dominant Java application framework. RestTemplate is its long-standing synchronous HTTP client and WebClient is its reactive, non-blocking client. Neither imposes a browser user agent; the default reflects the underlying HTTP machinery — which may surface a generic Java token or the token of the library Spring is configured to use.
Much of this traffic is service-to-service: microservices calling each other, or a backend calling a third-party API. It is automation by nature.
How it appears
Because the user agent depends on the underlying client, you may see a generic Java token, a library token (for whatever HTTP client backs WebClient or RestTemplate), or a custom user agent the developer set explicitly. There is no single fixed Spring user-agent string.
For reliable attribution, treat any of these server-side Java patterns as scripted traffic, and remember the string is a claim. Developers frequently set an explicit user agent for outbound integrations.
- No single fixed Spring user-agent string
- Default reflects the underlying HTTP client/library
- May appear as a generic Java token or a library token
How it appears in analytics and logs
A user agent showing a generic Java token or an underlying HTTP-library token, from a Spring app, indicates server-side automation — service-to-service calls or integrations — not a human browser.
Diagnostic use case
Attribute server-side Java traffic from Spring applications using RestTemplate or WebClient, and understand why the user agent reflects the underlying HTTP client.
What WebmasterID can help detect
WebmasterID classifies Spring-driven Java HTTP traffic as scripted, non-browser requests, helping keep service-to-service calls out of human analytics.
Common mistakes
- Expecting one fixed Spring user agent — it depends on the underlying client.
- Counting service-to-service Java calls as human page views.
- Assuming the absence of a Java token means no Spring client.
Privacy and accuracy notes
These tokens identify the HTTP stack, not a person. WebmasterID reads them as coarse automation signals only.
Related pages
- Java and OkHttp user agents
JVM HTTP clients send recognisable default user agents: Java's built-in URL connection uses a Java/version token, and the widely used OkHttp library uses an okhttp/version token. Both mark scripted or app traffic from the Java ecosystem, including many Android apps. This page covers the two patterns.
- Apache HttpClient user agent
Apache HttpClient, part of the Apache HttpComponents project, is a widely used Java HTTP client. Its default user agent contains an Apache-HttpClient token with a version. It is one of several common Java HTTP clients (alongside OkHttp and the JDK's own client) and marks server-side automation, not a browser.
- Detecting automation from user agents
You can use the user agent as a first signal for spotting automation — tool tokens, headless markers, missing strings — but it is never conclusive, because any client can change it. Reliable detection pairs the UA with verification and behaviour, and records honest unknowns. This page explains a sound approach.
- Bot intelligence
Surface server-side Java HTTP traffic separately from human visits.
Sources and verification notes
- Spring Framework — RestTemplate / WebClient documentationUser agent reflects the underlying HTTP client; no single fixed Spring UA.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.