ihmily/ip-info-api: Free IP Lookup Endpoints

What the ip-info-api catalog contains

ihmily/ip-info-api collects public HTTP endpoints that return information associated with an IP address. The intended audience is developers who need a quick source for a visitor's address, an approximate geographic location, an ISP name, or network metadata without arranging API credentials. The README describes the collection as a set of free IP query APIs and says that they can be accessed with GET requests without a key.

The repository is a catalog rather than a server or client library. Its top-level contents are `README.md` and `LICENSE`; there is no application package, deployment manifest, server implementation, or shared SDK in the repository layout. Each linked service retains its own host, parameters, output structure, CORS policy, and operational rules.

The directory separates endpoints by input model. Some can identify the caller or query an arbitrary supplied IP. Others only report the visitor's address because they derive the target from the incoming request. A smaller group accepts a particular IP but does not expose visitor lookup through the same interface. The README also reserves categories for reverse region lookup and retrieving only an IP address, although it does not provide detailed entries for those sections in the documented excerpt.

How each upstream endpoint handles an IP request

There is no unified data flow inside this project because the repository does not proxy requests or transform responses. A caller selects one of the listed upstream URLs and sends a GET request directly to it. For endpoints that accept an arbitrary address, the IP may appear as a query parameter or as part of the URL path. Endpoints restricted to the visitor's IP omit that target because the upstream service reads the network origin of the request.

The available entries do not share a response schema. The PConline example returns fields such as `ip`, `pro`, `city`, `addr`, and `err`. The `api.ip.sb/geoip/` example instead returns English-oriented fields including `organization`, `longitude`, `city`, `timezone`, `isp`, `asn`, `country`, and `region`. Another example uses a nested `data` object keyed by IP address. Client code written against one service therefore cannot assume that another service uses the same property names or nesting.

The README records request type, parameters, CORS support, request examples, and selected response examples for documented endpoints. Browser use also depends on those individual CORS records. For example, `https://api.ip.sb/geoip/` is marked as supporting CORS, while `https://whois.pconline.com.cn/ipJson.jsp?ip=&json=true` is marked as not supporting it. This is a service-level distinction, not a capability of the GitHub repository.

A first IP lookup with PConline and ip.sb

There is no installation procedure because ihmily/ip-info-api does not document a package, executable, container image, or runtime dependency. The README points readers to the linked endpoints for direct use. The first step is therefore to choose an entry that the README does not mark `已失效` and inspect its documented request pattern.

PConline accepts an optional `ip` query parameter. Omitting it requests the caller's own address according to the README. The following example URL is copied from its documented request example:

https://whois.pconline.com.cn/ipJson.jsp?ip=&json=true

The response shown in the README contains the detected IP, province, city, a combined address string, and an empty `err` field for the example address. The same endpoint uses a path-style address on ip.sb:

https://api.ip.sb/geoip/

Its documented example response contains fields such as `ip`, `country`, `region`, `city`, `isp`, `asn`, `latitude`, and `longitude`. These are example results from the README, not guaranteed live output. Consumers still need to handle the actual HTTP response and map fields explicitly.

Endpoint availability makes this a fragile integration directory

The most important limitation is visible in the README itself: numerous endpoints are explicitly marked `已失效`, meaning they have failed or are unavailable. The marks appear on services in the arbitrary-IP and visitor-only groups, including several entries that previously exposed CORS access. A URL listed in the catalog is therefore not evidence that it is operational.

The README also presents a fixed example IP, `121.8.215.106`, in many request examples. That makes the examples easy to understand, but it also means a reader cannot infer current data quality by seeing a populated JSON example. The repository does not document a health check, uptime record, schema version, rate limit, or automated removal policy for dead providers.

This design is reasonable for a discovery page, but weak as a production dependency registry. Code should not select an endpoint merely because it appears near the top of the README. It should test the exact status and response contract required by the application. If the selected service disappears, the catalog offers alternatives, but it does not provide a failover mechanism or a consistent adapter.

Why response normalization is left to the caller

A geolocation service can answer the same broad request with different field names, language conventions, nesting, and levels of detail. The examples show this directly. PConline's response is centered on Chinese administrative fields such as `pro` and `city`, while ip.sb includes network and coordinate metadata such as `asn`, `organization`, `latitude`, and `longitude`. The project does not publish a common JSON model that translates these shapes.

That choice avoids maintaining a proxy or SDK, but it transfers integration work to the caller. An application must define its own minimal schema, decide how missing fields are handled, and validate whether the upstream value represents the caller's IP or a supplied target. It also needs to account for endpoints that return plain address formats rather than JSON. The README includes plain endpoints such as `https://api.ipify.org` and `https://1.1.1.1/cdn-cgi/trace`, which are not interchangeable with structured geolocation responses.

A managed IP geolocation product would normally present one documented schema and one service contract. ihmily/ip-info-api instead offers direct access to independently operated services. That difference is the practical alternative: the catalog reduces initial discovery work, while a managed API reduces response-mapping and provider-management work.

Apache-2.0 coverage and upstream service terms

The repository identifies `Apache-2.0` as its license and includes a `LICENSE` file. That license applies to the repository's own documentation and listed contents under its terms. It does not establish that every linked endpoint is operated under the same license, nor does it document the terms, privacy policies, retention rules, or commercial-use conditions of the external services.

This distinction matters because an application may send visitor network information to a third-party host. The README does not describe how those providers handle IP addresses or whether they log requests. It also does not publish service-specific quotas. Before using any endpoint beyond an experiment, an engineer would need to inspect that provider's own terms and operational documentation. The repository's license cannot answer those questions.

Maintenance also differs between the catalog and its links. The repository is not archived, and its last push was on 2026-09-29. However, it has no GitHub releases, so there is no documented tagged upgrade path. A README edit can add or mark an endpoint without producing a release artifact, leaving consumers to monitor endpoint behavior independently.

Choosing between a listed endpoint and a managed API

The catalog is a better fit when the goal is to inspect several free options, build a small proof of concept, or retrieve a visitor address for a non-critical feature. Its direct GET examples and sample responses make it easy to identify candidate services without first selecting a commercial provider. The no-key model also removes a documented credential step.

It is the wrong choice for workflows that require a stable field contract, confirmed CORS support, documented rate limits, or a formal availability commitment. The README does not provide those guarantees, and it already labels many URLs as unavailable. Browser applications must also check CORS per endpoint rather than assuming that every listed service can be called from client-side JavaScript.

A managed IP geolocation API offers a different approach: the caller uses one provider interface instead of maintaining adapters for many unrelated endpoints. The trade-off is that the catalog documents no-key access and varied public services, while the managed alternative would add provider selection, credentials, billing, and vendor-specific terms outside the repository's documentation. For this project's stated goal, the choice comes down to discovery and experimentation versus a controlled production contract.

Editorial conclusion

Developers evaluating ihmily/ip-info-api can use it as a discovery list for a quick prototype or fallback experiment, but they should not make it the sole dependency of a production service. Operators needing a stable contract should first verify the intended provider, its current response format, CORS behavior, usage limits, privacy terms, and replacement path. The repository is best treated as a reference catalog, not an API service.

Frequently asked questions

Official sources

1. ihmily/ip-info-api on GitHub
2. Issues
3. License: Apache-2.0
4. README