Free Client IP API Endpoint

Call the free Client IP API endpoint

curl https://aisenseapi.com/services/v1/client_ip

{"ip":"46.212.190.81"}

That is the entire interface. There is no request body, no query string and no header to set. Paste the URL into a browser, run it in a shell, add it to a container entrypoint or drop it into a build step. One field comes back, and that field is the answer.

Response fields

Field	Type	Description
ip	string	The public address the request arrived from, in normal textual form: dotted quad for IPv4, colon separated hexadecimal for IPv6.

One field is the whole schema. Parsing stays trivial in any language, and a response that grows extra keys later will not break a client that reads only ip.

What the address really means

The value is the address the request arrived from as seen by this server. That is the public address of whatever NAT, proxy, VPN or cloud egress the traffic last passed through, not necessarily the machine that called.

Traffic from a home router, a corporate NAT, a proxy, a VPN or a cloud egress gateway reports the public address of that last hop, never the address on your own network interface. Every laptop on one office network normally sees the same value.

People read that as a flaw. It is the feature. Knowing which address the outside world attributes to you is a fact you cannot get by reading your own interfaces, and it is rarely written down anywhere you can trust.

Verify a VPN or an egress gateway

Because the free Client IP API endpoint reports the last public hop, it settles a question that guesswork cannot.

Call it before
Run the request with the tunnel down and write the address somewhere. This is your baseline.
Connect and call again
Bring up the VPN or route through the gateway, then repeat the same request.
Compare the two values
A changed address proves the tunnel really carries traffic to this destination. An unchanged address proves it does not, which usually means the tunnel is down, split tunnelling routes this destination around it, or something leaks.

The same three steps work from inside a pod. Call the endpoint there and you learn which public address a cluster workload actually leaves through, without depending on cloud metadata services.

IPv4 and IPv6

Both families come back in their usual textual form. Which one you get depends entirely on how the connection was made. A dual stack machine resolves the hostname, finds an A record and an AAAA record, then picks a family before any request goes out. A host you think of by its IPv4 address may hand you an IPv6 answer instead.

Force the choice with curl's -4 or -6 flag and compare the two answers. You learn both of your public addresses, which matters whenever a firewall rule or an allowlist was written for only one of them.

Response headers

A live call returns HTTP 200 with content-type: application/json. Two other headers shape how you can use it.

access-control-allow-origin: *
cache-control: no-store, no-cache, must-revalidate, max-age=0

The permissive CORS header lets browser JavaScript read the response directly, so a status page or a support widget can show a visitor their own address. The cache directives keep proxies and browsers from serving a stale value, which matters when you are checking an address that just changed.

Common uses

VPN and proxy verification

Call once before connecting and once after. The address either changes or it does not, and that answer is unambiguous.

CI runner allowlisting

Add the call as a pipeline step to discover the egress address a build leaves from, then allowlist it on a database, a partner API or a staging firewall.

Firewall rule debugging

When a rule that should match refuses to, compare the address the server really sees with the address written in the rule. A forgotten NAT hop explains most mismatches.

Container egress checks

Run it inside a container to confirm which NAT gateway that workload uses, with no platform specific tooling.

Agent self reporting

Let a language model or an automation report the address it calls from, without shell access.

Privacy and limits

The response contains nothing that every server you connect to does not already receive. This endpoint simply shows it back to you.

The service-wide limit is 5000 requests per IP per 24 hours, with no key and no account. Note that the counter keys on the same address the endpoint reports, so everyone behind one NAT or egress gateway shares a single budget. Remember that before putting the call in a tight polling loop.

To turn the returned address into a hostname, country and timezone, hand it to the IP Reverse Lookup API endpoint. To see what your client tells the server about itself, read the User Agent API endpoint. Every service in the family shares these limits, and the full catalogue lives on the free public REST APIs hub.