Build or write for IPLocate

Write an SDK or integration

We’re a small team, and we can’t do it all ourselves. That’s why we’re inviting you to help us.

If you’re a developer and your favorite programming language or framework is missing from our collection of official libraries, why not write one?

We would also love help integrating IPLocate into your favorite tools and services. Some already have a GeoIP or geolocation integration — bonus points for adding support for IPLocate.

If you would like to write and release an SDK or integration, please get in touch. If you follow our SDK guidelines, we’ll happily pay you a fair market day rate for your development time, either in money or in API credits.

SDK guidelines

While writing your SDK, we suggest you check out:

• the source code for our existing libraries on GitHub
• our API documentation
• our OpenAPI schema

Before you start, please check our list of libraries to ensure your language or framework is not already supported.

Ready to build? Here are our guidelines:

1. If you would like us to pay you, your library must be your own work. We think we can tell the difference between human-written and AI-generated code. For as long as that is still the case, we will not pay for libraries that are generated in part or fully by AI code generators like Copilot, Cursor, Amp and similar. You are still welcome to build an SDK using such tools, but we will not pay you for it.
2. Your library must be able to support an API key, and your documentation should include instructions on how to get a free one.
3. Your library should support all of the data points in our API responses. Please note that most of our API fields can be null, or missing entirely. We might add or remove fields at any time; your library should be able to handle this. For typed languages, we would love if your library returned parsed/typed objects, with an optional raw field. At minimum, your library should return the parsed JSON response as-is.
4. Your library should be able to handle all possible API errors, and return an error appropriate for the given programming language/framework. You can find detailed error codes and messages in our OpenAPI schema.
5. We only have one API endpoint, but we may have more in the future (We call the current endpoint lookup). You may want to keep this in mind when architecting your library.
6. Calling our API endpoint without an IP address is valid — in this case, we will return the response of the calling IP address. Your library should handle this; it’s up to you how you do it — either by allowing a blank or null value to your lookup method, or a separate method like lookup_self.
7. Optional: To help users stay within their usage quotas, you might consider including an optional in-memory cache that stores results for previously looked-up IP addresses for a configurable duration.
8. Please use a unique user-agent string, so we can see how different libraries are being used. Ideally the user-agent string should also include the version of your library.
9. We have licensed our libraries under the MIT license. You don't have to use the same one, but please add a license to your code.
10. Our existing libraries are a good reference, but don’t feel bound to conventions or patterns that they use. We would prefer each library to align with the conventions of the language or framework it is written in.
11. Please include a test suite covering, at minimum, basic library functionality. You can refer to our existing libraries for examples.
12. Please set up an automated build and test process using GitHub Actions or similar, and include the build status in your README.
13. In your README please list any relevant prerequisites that need to be installed for your code to work. Ideally show the exact commands needed to install those requirements.
14. Please submit your code to the relevant package manager (npm, pypi, maven, etc.) for that language, and link to this in the README.
15. Please include some examples in your README for some common use cases, like looking up geolocation data for a given IP address, handling errors, looking up privacy information, and so on. Your README should also link to our API documentation.
16. Finally, please let us know what you’ve built so that we can feature it on our website and on our blog!

Thanks again for your interest in building for IPLocate! We really appreciate it. If you have any questions, please ask us — we’re here to help.

We are happy to pay a fair market day rate for SDKs that meet these guidelines. Please note, we are not obligated to accept or pay for any unsolicited SDKs or submissions. Any payment is contingent on being formally accepted by the IPLocate team. We reserve the right to refuse any submission that does not meet our quality standards, including any submission that we suspect includes AI-generated code.

Write for IPLocate

We’re always looking to expand our library of practical tutorials, step-by-step guides, and real-world use cases. You can find some examples of these on our blog.

If you’ve written a blog post or tutorial, or would like to write one, we’d love to feature it on our website. We’ll also pay a fair market rate for accepted articles that help our community learn new ways to use IP data.

We’re looking for:

• Tutorials and guides on how to integrate IP address data, particularly for programming languages and frameworks that we haven’t covered yet. Anything from “getting started” guides to specific tasks and demos.
• Stories about real world use-cases, integrations, or post-mortems on how IP address data was used to solve a particular problem.

Interested? Get in touch to let us know about an article you’ve written, or to discuss something you’d like to write.

Our writing guidelines are simple:

1. Your article should solve a practical problem or build a useful tool using the IPLocate API. We are especially interested in guides for specific languages and frameworks, and use cases like threat analysis, content personalization, or data enrichment.
2. Please write for a technical audience. Your readers will be developers, engineers, and security professionals. You can assume they are familiar with their chosen programming language, so you can focus on the core logic of the tutorial.
3. Just like our SDKs, your article must be your own original work. We will not accept AI-generated content under any circumstances. If you have a great story that just needs some finishing touches, let us know. Please don’t just run it through ChatGPT. We would rather pay for the rough human-written version. Really. We will not pay for AI-generated content.
4. The article should be clear, well-structured, and easy to follow. This comes in many different shapes and sizes, depending on what you’re writing about. For a tutorial, we suggest including a brief introduction that explains what the reader will build, a list of prerequisites, and clear step-by-step instructions with code snippets.
5. All code examples must be accurate, well-explained, and easy for the reader to use. Linking to a public GitHub repository with the complete, working code is highly encouraged.
6. Any links you include should be natural and provide real value to the reader. You are welcome to include a link to your own blog or website, including to another commercial service, if it is relevant to the article. We will not accept content that is written primarily for SEO or to acquire backlinks.
7. You can publish the article wherever you like, and retain all rights to it. With your permission, we’ll publish the article or tutorial on our website with your name and a byline, giving you full credit for your work.

If you have already written something, please let us know about it and we’d love to feature it.

If you’re looking to write for IPLocate, please contact us with your idea first to make sure it’s a good fit. In your message, please include a brief outline of your proposed topic and a link to some examples of your previous writing.