Web - Client

Free User Agent API Endpoint

The free User Agent API endpoint is a mirror for one header. Send a request and it hands back the exact User-Agent string it received, so you can see what your client is really telling servers rather than what you believe you configured.

  • No API key
  • One GET request
  • Echoes verbatim
  • Debugging tool

Echo your User-Agent

GET/user_agent

https://aisenseapi.com/services/v1/user_agent

Read your own header back

One GET request does the whole job. The example below sets the header explicitly with curl's -A flag, so you can run it yourself and get exactly the same answer.

curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0" \
  https://aisenseapi.com/services/v1/user_agent
{"user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0"}

Whatever follows the flag comes back untouched. That is the entire contract, and it is what makes the call worth making.

Now drop the flag. Curl still sends a header, because it supplies its own default when you do not set one.

curl https://aisenseapi.com/services/v1/user_agent
{"user_agent":"curl/7.88.1"}

Your version number will differ. The lesson does not: a tool identified itself without being asked, which is precisely the kind of surprise this endpoint exists to surface.

What the free User Agent API endpoint returns

FieldTypeDescription
user_agentstringThe User-Agent header exactly as it arrived, with no parsing, normalisation or truncation. A request that carries no User-Agent header at all returns the string unknown.

One field, and no interpretation. The response does not split the string into browser, engine and platform, and it never guesses at a device or an operating system. You get the raw value and you decide what it means.

Sending an empty header is the quick way to see the fallback:

curl -A "" https://aisenseapi.com/services/v1/user_agent
{"user_agent":"unknown"}

An absent header and an empty header therefore land in the same place. If you need to tell those two cases apart, you need server logs rather than an echo.

Why an echo endpoint earns its keep

  1. What you set is not always what is sent

    HTTP libraries append their own identifiers to a User-Agent you configure, or quietly ignore your value because it was set on the wrong object. Requests, Guzzle, OkHttp, axios and the rest all have their own rules about precedence and defaults. The received string settles the argument in one call.

  2. Proxies and gateways rewrite headers

    Corporate proxies, CDNs, API gateways and service meshes sit between your process and the origin, and several of them normalise or replace User-Agent on the way through. If your crawler identifies itself correctly on your laptop but gets blocked from a deployed environment, comparing the echoed value from both places tells you whether the header survived the hop.

  3. Some clients send nothing

    Bare socket code, minimal HTTP clients and hand-rolled request builders often omit User-Agent entirely. Servers that log or rate-limit on that header see an empty slot, which is worth discovering before a partner does.

  4. It is the fastest wire-level check available

    No packet capture, no server access, no log grepping. One request against an endpoint that reflects the header back is the shortest path from a question about what is going over the wire to an answer.

Self-reported and trivially forged

A User-Agent is self-reported and trivially forged. Anyone can send any string, as the curl example on this page demonstrates. Never use it for access control, authentication, or as any kind of identity signal. Treat it as a hint for diagnostics and analytics, nothing more.

The first example proves the point in a single line. A plain command line claimed to be Chrome on Windows, and the server had no way to know otherwise. Nothing about the header is verified, because nothing about it can be.

That is worth stating plainly, because gating features or blocking traffic on a User-Agent string remains common. It stops honest clients and misses dishonest ones. Use it to explain behaviour after the fact, never to decide who gets in.

Common uses

Crawler identification

Confirm a custom User-Agent for your bot is actually being sent before you point it at other people's sites.

Proxy debugging

Call the endpoint from inside and outside a proxy and compare the two strings to see exactly what was rewritten.

SDK verification

Check that a client library identifies itself the way its documentation claims, including any version suffix it appends.

Teaching request headers

Show a class what a header is by letting them change one value and watch the response change with it.

Agent self-inspection

Let an automated agent discover how it presents itself to servers without needing access to any server logs.

Each of these reduces to the same question. Something on the wire is not what you expected, and the free User Agent API endpoint answers it faster than adding logging to a server you may not control.

Privacy and limits

The endpoint reflects one header back to the caller and stores nothing. Nothing is written down, and nothing is returned that you did not send.

The service-wide limit is 5000 requests per IP per 24 hours, with no key and no account behind it.

Header inspection rarely travels alone. The Client IP API endpoint answers the matching question about the address a server sees, and the IP Reverse Lookup API endpoint fills in the detail behind that address. When you want to know whether the service is up before you debug anything else, the Ping API endpoint is the one-line check.

Every endpoint on the service, including this one, is listed in the free public REST APIs reference. Read the free User Agent API endpoint alongside those neighbours and you can describe a request from both ends: who the caller claims to be, and where the call actually came from.