You have already witnessed how powerful the PQAI API can be for semantic patent search. Now you want to bring that same intelligence into your organisation’s tools. 

Maybe you want to build novelty checking features inside your idea portal. Or enrich your invention disclosure workflows. Or you want your R&D tools to flag risks before they reach the IP team. 

The good news is that getting started with the PQAI API is extremely simple. Even though the API is flexible and can support many different workflows, you only need a few core endpoints to run meaningful novelty checks. This guide will show you exactly how to set that up with minimal effort.

The Core PQAI API Endpoints That Power Novelty Checking

To build novelty checking features inside enterprise tools, you only need two key PQAI endpoints. These handle semantic search and multi-document combination retrieval, which are the building blocks of novelty assessment.

Below is what each endpoint does, how developers typically use it, and an example you can run instantly.

/search/102 for Semantic Prior Art Search

This endpoint takes a natural-language idea description and returns the most relevant patents or NPL documents. It is the main route behind first-level novelty checks, triage screens, and invention-submission scoring.

For instance, when an inventor submits an idea like “a drone that detects fires using thermal imaging,” your system can call /search/102 and instantly surface top semantically relevant patents.

Example request https://api.projectpq.ai/search/102 q=fire%20detecting%20drone&n=5&type=patent&token=YOUR_TOKEN

The request will return a JSON array of patent hits with publication numbers, titles, similarity scores, snippet matches (optional), and CPC alignment.

/search/103 for Multi-Document Combination Search

Novelty often depends on combinations, not one document alone. /search/103 returns combinations of prior art that collectively cover different elements of the submitted idea.

Teams use this endpoint when:

• the concept is complex
• multiple technical elements must be matched
• reviewers need stronger evidence of overlap

Example https://api.projectpq.ai/search/103?q=fire%20detecting%20drone&n=5&type=patent&token=YOUR_TOKEN

This gives structured multi-document groupings that help reviewers evaluate composite prior art coverage. It also follows the same pattern examiners use when they combine multiple references during examination, especially in situations that lead to 103-type rejections.

All in all, these two endpoints alone can power most enterprise novelty checking systems, from idea portals to automated R&D review systems.

How a Novelty-Checking Workflow Works Inside an Enterprise System

A novelty check inside an enterprise system is simpler than it looks. An inventor submits an idea, your backend sends a text query to PQAI, and the API returns the closest prior art in seconds. Here’s the typical flow:

Idea submitted: An inventor enters a short description inside your idea portal or R&D tool. Your backend receives plain text, which becomes the query.

Run the first semantic check: Your system calls /search/102 with just two things:

• the query text
• your API token

This alone triggers a full semantic search. PQAI returns the most relevant patents, similarity scores, and snippets. Parameters like n, type, after, etc. are optional and can be added later. 

Run deeper checks: If the idea is complex and you want to see multi-document combinations that together cover different claim-level elements, your system can call /search/103. This can give reviewers a richer view of overlapping prior art.

Apply your logic: Your backend can score, classify, or route ideas based on the API response. Most teams plug this into their existing review workflow.

Show the results: Your UI can now display the closest prior art, snippets, and similarity indicators so reviewers can make quick decisions.

For most enterprise use cases, this entire workflow runs through two or three API calls at most, making it fast to onboard and easy to maintain.

At this stage, many teams also start evaluating whether they should build their own patent search API or rely on existing top APIs. If you are thinking along the same lines, this guide on making the build-vs-buy decision can help you make an informed decision.

Code Examples: Running a Novelty Check in Python and JavaScript

Here are two minimal implementation snippets you can drop directly into a backend or workflow script. 

Example 1: Implementing a Novelty Check in Python

This is the smallest possible Python block that runs a complete first-level novelty check using PQAI’s semantic search.

import requests token = “YOUR_API_TOKEN” url = “https://api.projectpq.ai/search/102” params = {     “q”: “a drone that uses thermal imaging to detect fire hotspots”,     “n”: 10,     “type”: “patent”,     “token”: token } res = requests.get(url, params=params) results = res.json().get(“results”, []) for r in results:     print(r.get(“pn”), r.get(“title”), r.get(“score”))

This query will give you a JSON list of the closest prior-art documents with similarity scores. Most enterprises store this JSON internally and show it to reviewers inside dashboards or workflow tools.

Example 2: Implementing a Novelty Check in NodeJS

If your system is built in JavaScript or Node.js, the same workflow is just as simple.

const axios = require(“axios”); const token = “YOUR_API_TOKEN”; const url = “https://api.projectpq.ai/search/102”; axios.get(url, {  params: {     q: “a drone that uses thermal imaging to detect fire hotspots”,    n: 10,    type: “patent”,    token: token   } }). then(res => {   const results = res.data.results || [];   results.forEach(item => {     console.log(item.pn, item.title, item.score);   }); }) .catch(err => {   console.error(“Request failed:”, err.message); });

This should give you a clean result set your frontend, backend, or internal dashboard can render instantly.  Teams often add a second follow-up call to /search/103 based on their workflow.

How to Add Scoring, Flags, and Risk Indicators on Top of PQAI Responses

Once you have the raw PQAI results, the next step is to convert them into signals your reviewers can act on. 

Most enterprise systems add a thin logic layer on top of the API output based on similarity scores and metadata.

Here are the most common ways you can turn PQAI responses into internal scoring and risk indicators:

1. Use similarity scores to assign flags
PQAI returns a score field that represents semantic closeness.
You can convert it into flags like:

• High overlap → score ≥ 0.80
• Medium overlap → 0.60–0.79
• Low overlap → below 0.60

These thresholds can be tuned based on your domain.

2. Show traffic-light indicators in the UI

Many enterprise UIs display a simple status next to each idea:

• Red = potentially risky
• Yellow = partially overlapping
• Green = likely novel

This makes triage much faster for reviewers.

3. Combine signals if needed

Some teams merge semantic score + CPC overlap into a single value, but this is optional. If you want, you can compute a simple weighted score and store it with the idea.

4. Auto-route ideas based on the flag

Once a flag is assigned, you can route it accordingly:

• Red → route to IP counsel
• Yellow → send to senior reviewer
• Green → fast-track

This makes your novelty-check workflow automated and consistent.

Before You Go

Building novelty checking features inside an enterprise system does not require a large pipeline or complex architecture. With just a few PQAI API calls,your backend can run semantic searches, detect possible overlap, generate reviewer-friendly signals, and flag potential risks automatically.

The API responses are structured, predictable, and easy to plug into dashboards, idea portals, invention disclosure tools, or internal R&D workflows. Most teams only add a small layer of logic on top of the JSON output to generate scores, flags, and routing decisions.

If your organisation wants to embed semantic novelty checking inside its internal tools, the PQAI API gives you a fast and reliable way to make it happen. And if you need help designing the workflow or integrating it into your stack, we can support you with implementation. You can fill this form for more information.