This repo tracks our official client libraries and integrations.
Official libraries for common programming languages, like PHP, Python etc.
See GUIDELINES for implementation guidelines.
| Language | Status | Link | Package Manager | Published Link |
|---|---|---|---|---|
| Javascript (Node) | Released | ipinfo/node | npmjs | node-ipinfo |
| Java | Released | ipinfo/java | Maven Central | ipinfo-api |
| Python | Released | ipinfo/python | PyPI | ipinfo |
| C# | Released | ipinfo/csharp | Nuget | IpInfo |
| PHP | Released | ipinfo/php | Composer | ipinfo/ipinfo |
| Ruby | Released | ipinfo/ruby | Ruby Gems | IPinfo |
| Go | Released | ipinfo/go | GitHub | ipinfo/go |
| R | Proposed | CRAN | ||
| Perl | Released | ipinfo/perl | CPAN | Geo-IPinfo |
| Erlang | Released | ipinfo/erlang | hex.pm | ipinfo |
| Rust | Released | ipinfo/rust | crates.io | ipinfo |
Official libraries for common frameworks. These libraries should use the official lanaguge library as a dependency, so for example the Django library should use the Python library.
In the framework libraries we can assume more about the developer's use case, and we probably have access to more information, such as a HTTP request object. We can therefore implement additional functionality that doesn't make sense in the core language library. This includes bot filtering (not sending requests to our API if the user agent belongs to a "bot").
The framework libraries should make it as simple as possible to use our API. For example, ideally only a few lines of code would be required to get IPinfo data for everyone accessing your Ruby site.
| Framework | Status | Link | Published Links |
|---|---|---|---|
| Express (NodeJS) | Released | ipinfo/node-express | ipinfo-express |
| Spring (Java) | Released | ipinfo/spring | ipinfo-spring |
| Laravel (PHP) | Released | ipinfo/laravel | ipinfo/ipinfolaravel |
| Django (Python) | Released | ipinfo/django | ipinfo-django |
| Rails (Ruby) | Released | ipinfo/rails | ipinfo-rails |
For many developers our libraries will be their first contact with our service - they'll never have been to our website, or read anything else about us. Therefore it's important to do a good job of explaining the service to them in the library documentation. See our standard HEADER and FOOTER that should be added to every README.
The libraries are also a great opportunity for new developers to discover us, so we should make sure we include relevant search terms in our description and summary text, and keywords if applicable.