Intelligence X SDK: a public client for the intelx.io search engine

One search engine, six ways to reach it

Intelligence X describes itself in the README as a search engine and data archive, and the SDK is the client library set for it. The stated purpose is broad: the SDK allows anyone to use the Intelligence X search engine, it is free to use, and Intelligence X welcomes any integrations into third party tools and services.

What the repository actually contains is listed in the README as six parts, and the list is the best description of the project available.

1. API documentation, in the form of a PDF named Intelligence X API.pdf 2. An HTML code example, in HTML/search.html 3. A PHP code example, in PHP/index.php 4. Python code examples, in Python/examples 5. A Go package and code, in Go/ixapi/ 6. A Maltego Transform, in a directory named Maltego Transform/

The top level of the repository adds two things the README does not list in its numbered set: an openapi.yaml with an openapi.md beside it, and a docs/ directory. There is also a JavaScript/ directory that the numbered list skips, and an httpie.md file describing how to drive the API with HTTPie. The .yamllint file at the root suggests the OpenAPI document is linted in CI, and there is a .github/ directory for the workflows.

The primary language of the repository is Python, the default branch is master, and the last push was on 2026-10-03. There are no GitHub releases, and the copyright line in the README reads 2018 to 2025 Intelligence X.

The selector types, and the rule that anything else is rejected

The most specific technical constraint in the README is about what the search engine will accept. It supports only the following strong selector types, and anything else will be rejected.

The list is: email address, domain including wildcards like *.example.com, URL, IPv4 and IPv6, CIDRv4 and CIDRv6, phone number, bitcoin address, MAC address, IPFS hash, UUID, simhash, credit card number, social security number, and IBAN.

That list defines the shape of any integration. A tool built on this SDK has to turn whatever the user is searching for into one of those fourteen forms, and a search for a phrase or a person's name has no representation in the API at all. The word strong in the README's phrase about strong selector types carries the same weight: the engine is not a general web search with a filter panel, it is a lookup keyed on identifiers.

The wildcard on domains is the one flexibility in the list, and it is the reason domain searches are the common case. A query for *.example.com covers every subdomain, which is a different operation from a query for a single host and returns a different result set.

The domain and URL selectors, combined with the IP and CIDR entries, are also the only entries that describe network infrastructure rather than an identifier of a person or an account, and that distinction shapes what an integration can be used for.

Linking instead of integrating

The README offers an alternative to using the API at all, and it does so with a piece of self-deprecating phrasing: instead of directly using the API, you can always do the ghetto version instead and just link to the website.

The mechanism is a query parameter on the site, and the search term goes in the s parameter.

https://intelx.io/?s=[search term]

The examples given are a domain and an email address.

https://intelx.io/?s=test.com
https://intelx.io/[email protected]

This matters for anyone deciding whether they need the SDK at all. A tool that only wants to send a user to a result page does not need a key, does not need an SDK dependency, and does not need a licence conversation. A tool that wants to read results programmatically does.

The distinction also frames the difference between the search engine and the archive. The engine is the public facing part, and the archive is the historical corpus behind it, and the SDK is what gives programmatic access to the results that the archive produces.

Getting a key, and the licence constraint that decides the whole design

The authentication paragraph is short and has two sentences that change what you can build.

The first says you will need an API key, which you can obtain at the developer tab of an account at intelx.io. The second says that integration into your commercial service or product requires a paid licence. The third adds that if your product is open source, do not embed your API key, and the fourth states that the use of public API keys is discontinued.

Those four constraints together mean there is no free tier in the usual sense. A key is tied to an account and, for anything commercial, to a paid arrangement. The open source case is handled by instruction rather than by an automated mechanism: the key is not embedded, which means the user supplies their own or the integration is unusable out of the box.

The discontinuation of public API keys is the change that matters for anyone reading older documentation about this service. A shared key baked into an open source tool is no longer a workable pattern, and a tool that shipped one would now be broken.

The Terms of Service at intelx.io/terms-of-service apply, and the README is explicit that they do. The repository's own licence field records no licence, so the code in it is not offered under a named open source licence, which is a separate question from the terms under which the service itself may be used. A team considering this SDK should treat those as two separate reviews: one of the code, and one of the service terms.

The Python package moved, and the update history is dated

The latest updates section of the README is a dated log rather than a changelog, and one entry is struck through, which is itself informative.

The most recent entry says that on 30.11.2024 version 0.6.2 is installable from the Python Package Index, with the package listed as intelx. The entry before it, 06.06.2024, notes that Python supports the Export Leaked Accounts feature of identity.intelx.io. The struck-through entry, 02.02.2024, records that the Python Package moved to a separate GitHub repository, IntelligenceX/Python, and the strikethrough marks it as obsolete information.

That is the single most actionable line in the README for a Python user. The examples in the Python/ directory of this repository are not where the current Python package lives, and the package index entry is the supported install route.

The older entries show the shape of the project's development. A new Maltego Transform in July 2020, an additional filter for phonebook-style lookups in the Python code in June 2020, and a new Python API wrapper and command line interface in April 2020. So the Python client was a late addition relative to the repository itself, and the command line interface has been part of it since that first release.

The Maltego transform deserves a note for anyone working in OSINT. The README does not describe how the transform works internally, so anyone using it should rely on the Maltego Transform README in the repository for setup and usage details.

Where this SDK is the wrong tool

Three cases point elsewhere. The first is a product that needs the search results embedded in its own commercial offering. The README is unambiguous that this requires a paid licence, and the prohibition on embedding a key in an open source product means there is no free path to shipping the service inside someone else's product. A team that needs the data rather than a link to it has to talk to Intelligence X about terms first, and that conversation is the gating step.

The second is a project that needs general web search or searching by free text. The fourteen selector types are the limit. A query for a name, a phrase or a company does not map onto any of them, and the README says anything else will be rejected. A tool whose users want to type a natural language query needs a different engine.

The third is a team that wants to run the archive itself. This is a client for a hosted service, not a self-hosted index. The repository contains examples and clients, and the data lives at intelx.io.

The alternative worth weighing is the bare REST API with no SDK at all, which the openapi.yaml and openapi.md in the repository make straightforward. The difference in approach is that the SDKs save you the request construction and the response parsing, and in exchange they lock your code to a client whose maintenance you do not control, since the Python package has already been moved out of this repository once. For a one-off script, a hand-written request against the documented endpoints is fewer moving parts than a dependency; for a long-lived integration, the Go package and the Maltego transform are the more durable shapes, because they are less likely to be relocated.

Editorial conclusion

Intelligence X SDK fits a researcher or analyst who already has an account and wants the intelx.io search surface inside an existing tool, a Maltego graph, or a script, and who has checked that their intended use is within the licence they hold. It does not fit a product that intends to embed the service commercially, because the README states that integration into a commercial service or product requires a paid licence, and it does not fit anyone expecting a shared public key, since the use of public API keys is discontinued and each key comes from the developer tab of an account. Before you build anything on it, read the Terms of Service at intelx.io/terms-of-service, and check the Python package, whose README entry points at a separate repository for the current release.

Frequently asked questions

Official sources

1. IntelligenceX/SDK on GitHub
2. Issues
3. Project website
4. README