You have already explored what PQAI can do. 

Now you want to bring its semantic patent search into your own product or tool. Maybe you are building a dashboard or a novelty check feature. Or perhaps your own IP analysis system. Whatever the use case, you are looking for a clear guide to integrate the PQAI API.

The good news is that the PQAI API is flexible and capable of supporting many different workflows. So getting started is really simple. You only need a few key details to begin using it meaningfully. This guide walks you through those essentials so you can start integrating PQAI quickly and confidently in your application.

What You Need Before You Start

Before you integrate the PQAI API, make sure you have the basics in place. You only need a few things, which you might already have handy.

1. Your PQAI API token: You can get this token after upgrading to a PQAI+ Individual or Enterprise plan. Academic users can request a free token by emailing sam@projectpq.ai

2. A code editor: It could be VS Code, PyCharm, Sublime Text, or any editor of your choice. 

3. Python or NodeJS installed: The examples in this guide use both. Pick the one you are comfortable with.

4. A browser or cURL for quick URL tests. Most PQAI routes accept simple GET requests too.

Once you have these, you are ready to make your first API call.

How to Make Your First API Call

Once you have your API key, you can make your first call in a few seconds. PQAI supports simple GET requests, so you can test the API right from your browser or command line.

If you want an instant result without authentication, start with a patent drawing. This route does not require a token.

https://api.projectpq.ai/patents/US7654321B2/drawings/1

If you open this URL in your browser,  you should be able to see a drawing from the patent. You can replace the patent number and drawing index to explore more.

This should give you a quick sense of how the API responds and how routes are structured. Once this works, you can move on to an authenticated request with your token.’

How To Run Your First Semantic Search Query

Now that you have seen how a simple GET request works, let us move to the real reason developers use PQAI: our semantic prior art search.

PQAI’s main search endpoint is:

/search/102

This route takes your natural language query and returns the most relevant patents or NPL documents. You can access it by adding parameters to the URL.

Here is a basic example with the minimum required fields:

https://api.projectpq.ai/search/102?q=fire%20fighting%20drone&token=YOUR_API_TOKEN

PS: You need to replace YOUR_API_TOKEN with your actual key.

This request will return patents related to the idea of a fire fighting drone. You can change the query text, the number of results, and the document type.

The response comes back in JSON format. Each item contains the publication number, title, score, publication date, and other fields you can use directly inside your application.

This is the fastest way to test PQAI’s semantic engine and verify your token is working.

How to Integrate PQAI Search in Python

If you prefer working with Python, you can make your first PQAI API call with just a few lines of code. The API uses simple GET requests, so you only need the requests library.

Here is a ready-to-run example:

Here is a ready-to-run example:

import requests token = “YOUR_API_TOKEN” endpoint = “https://api.projectpq.ai” route = “/search/102” url = endpoint + route params = {     “q”: “a fire fighting drone”,     “n”: 10,     “type”: “patent”,     “after”: “2016-01-01”,     “token”: token } response = requests.get(url, params=params) if response.status_code == 200:    results = response.json().get(“results”, [])     for r in results:         print(r.get(“pn”), r.get(“title”)) else:     print(“Request failed”, response.status_code)

You can replace YOUR_API_TOKEN with your key and run the script. You will get a list of publication numbers and titles related to your query.

You can modify the query, filter by date, or change the result count to fit your application. This simple block is enough to embed PQAI search into any Python workflow or backend.

How to Integrate PQAI Search With JavaScript

If your application is built in JavaScript, you can call the PQAI API using any HTTP client.

The example below uses the popular axios library, but you can use fetch, request, or any other method you prefer.

Here is a simple example:

const axios = require(“axios”); const token = “YOUR_API_TOKEN”; const endpoint = “https://api.projectpq.ai”; const route = “/search/102”;const url = endpoint + route; axios.get(url, {   params: {     q: “a fire fighting drone”,    n: 10,  type: “patent”,     after: “2016-01-01”,     token: token   } }). then(res => {   const results = res.data.results || [];   results.forEach(item => {     console.log(item.pn, item.title);   }) ;}) .catch(err => {   console.error(“Request failed”, err.message); });

You can replace YOUR_API_TOKEN with your key here as well and then run the script. It will return a list of relevant patents returned by PQAI’s semantic engine.

This snippet works in any Node.js environment and can easily be adapted for browser-based projects using fetch.

A list of all PQAI API Routes Developers Can Use

PQAI offers a complete set of API routes that cover search, similarity, classification, patent data, drawings, and document retrieval. 

You may not need every route in your workflow, but it helps to know what is available. Each endpoint is designed to plug into real developer use cases, from semantic prior art search to CPC prediction and patent metadata extraction.

Below is the full list of PQAI API routes along with what each one is used for.

Route	What It Does
/search/102	Runs a semantic prior art search using natural language. Returns the most relevant patents or NPL documents.
/search/103	Finds prior art combinations. Useful for multi-document coverage of different query elements.
/prior-art/patent	Returns documents published before the filing date of a given patent. Ideal for novelty checks.
/similar	Finds patents most similar to a specific patent number based on semantic vectors.
/snippets	Generates a snippet showing how a document matches the provided query text.
/mappings	Returns element-wise mapping between a query and a document. Useful for claim-level analysis.
/datasets	Retrieves a sample item from a PQAI dataset. Helpful for tests and benchmarks.
/documents	Fetches a document directly from the PQAI database using its ID.
/patents/{pn}	Returns full metadata for a patent, including title, dates, inventors, assignees, and abstract.
/patents/{pn}/drawings/{n}	Returns a full-size patent drawing. Token not required.
/patents/{pn}/thumbnails/{n}	Returns a thumbnail of a drawing. Supports width and height parameters.
/patents/{pn}/drawings	Returns a list of all drawings for a patent.
/patents/{pn}/thumbnails	Returns a list of all thumbnails for a patent.
/patents/{pn}/vectors/{field}	Returns the vector representation of a patent. Field can be CPC vector or abstract vector.
/suggest/cpcs	Suggests CPC classes based on a text excerpt. Useful for classification or drafting.
/predict/gaus	Predicts the most relevant USPTO Group Art Units for the provided text.
/definitions/cpcs	Returns the official definition of a CPC code.
/docs	Returns the full PQAI API documentation in HTML format.

What Kind of API Responses Can You Expect from PQAI API?

By this point, you have seen how PQAI routes work. 

The responses are consistent across the API, and most of them follow a simple structure that developers can parse immediately.

PQAI returns JSON for most routes and PNG images for drawing related routes. 

The search responses include a results array with fields such as publication number, title, similarity score, publication date, and CPC codes. 

Moreover, vector routes return numeric arrays that represent the semantic structure of the patent. Drawing and thumbnail routes return PNG files that you can use directly in your interface without additional processing.

Where You Can Use the PQAI API in Your Workflow

The PQAI API fits naturally into many developer workflows and internal tools. Whether you are building something simple or a full IP intelligence system, these are the most common applications.

1. Adding semantic patent search to your product: You can use /search/102 to power natural language search inside dashboards, internal portals, or custom research tools.

2. Running prior art checks inside invention workflows: You can peruse /prior-art/patent and /similar when the inventor references an existing patent or published application. For example, it could improvement ideas, continuations, or comparison workflows.

3. Automatic CPC classification in drafting or routing tools: Leverage /suggest/cpcs to classify text from invention notes, internal reports, or research summaries.

4. Enriching your interface with patent metadata and drawings: Use /patents/{pn} and drawing routes to display abstracts, inventor data, drawing pages, or thumbnails inside your UI.

5. Using patent vectors for clustering or similarity models: Use /patents/{pn}/vectors/{field} to get vector embeddings for ML workflows or semantic organization of patent sets.

These applications cover how most teams bring PQAI into their internal tools, dashboards, R&D workflows, and automated processes. 

You can start with any one of these and expand as your use cases grow.

Before You go

Integrating the PQAI API is straightforward. Once your token is ready, you can run semantic searches, retrieve prior art, pull patent metadata, generate CPC suggestions, and fetch drawings with only a few lines of code. 

The routes are predictable, the responses are consistent, and most use cases can be handled with simple GET requests.

If you want to explore more, the full API documentation can be found here. You can also reach out to us if you need help building PQAI into your workflow or want to discuss advanced integrations.