SaaS, AI & Developer Infrastructure
Enterprise Search API
Your product holds documents, tickets, records and comments. Your search box almost certainly matches on words, which is why your customers say they cannot find anything.
- SaaS platforms
- Intranet and workplace vendors
- Knowledge management software
- Support desk vendors
- AI assistant builders
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Search is the feature every B2B product has and almost none does well. The usual implementation is a keyword index over one table, which works when the user remembers the exact phrase and fails the moment they describe what they want in their own words. The support ticket for 'the thing about refunds in the Netherlands' never matches a document titled 'EU consumer withdrawal policy v4'.
The harder part is not relevance, though. It is permissions. Enterprise search spans sources with different access models, and a result set that leaks one paragraph from a document the user was not meant to see is a security incident, not a relevance bug. Doing this correctly means enforcing permissions at query time against the source system's current state, not against whatever was true when the document was indexed.
Beyond that sit the unglamorous problems that decide whether people trust the search box: near-duplicate documents from version sprawl, confidently retrieving a policy that was superseded eighteen months ago, and connectors that quietly stop syncing. Each is tractable. None is interesting enough that product teams prioritise it over features customers ask for by name.
Who buys this
SaaS platforms, Intranet and workplace vendors, Knowledge management software, Support desk vendors, AI assistant builders
What the API returns
What comes back
- Ranked results across connected sources with a per-result relevance explanation
- Permission-filtered retrieval evaluated at query time, per end user
- Passage-level answers with citations back to the exact section
- Structured filters on source, author, date, document type and custom metadata
- Freshness and supersession signals so stale policy documents are demoted or labelled
- Near-duplicate collapsing across versions and copies of the same document
- Query understanding: acronym expansion, synonyms and your customers' internal vocabulary
- Zero-result and abandoned-query reporting, which is the most useful content gap signal you will get
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/search | Ranked results for a query, scoped to one end user's permissions |
| POST | /v1/answer | A synthesised answer with citations, or an explicit refusal |
| POST | /v1/index | Index or update documents and records for a tenant |
| GET | /v1/sources | Connected sources with sync status and last successful run |
| POST | /v1/feedback | Click and usefulness signals used to tune ranking |
| GET | /v1/analytics/gaps | Queries returning nothing useful, ranked by frequency |
Request and response
illustrativeRequest
{
"tenant_id": "acme",
"user_id": "u_8812",
"query": "how long does a customer have to cancel in the netherlands",
"sources": ["documents", "tickets", "wiki"],
"filters": { "updated_after": "2024-01-01" },
"limit": 5,
"explain": true
}Response
{
"query_id": "q_61c4a0",
"latency_ms": 184,
"permission_mode": "live_check",
"results": [
{
"title": "EU consumer withdrawal policy v4",
"source": "documents",
"updated_at": "2026-03-11",
"score": 0.91,
"passage": "Consumers in EU member states, including the Netherlands, have 14 calendar days from delivery to withdraw without reason.",
"citation": { "doc_id": "d_3312", "section": "3.2", "page": 7 },
"why": ["semantic match on 'cancel' to 'withdrawal'", "recency boost", "policy source type"]
},
{
"title": "Ticket #44120 — NL cancellation dispute",
"source": "tickets",
"updated_at": "2026-09-02",
"score": 0.68,
"passage": "Confirmed with legal: 14 days, extended to 12 months if no withdrawal notice was given.",
"citation": { "ticket_id": "44120", "comment_id": "c_9" },
"why": ["semantic match", "resolved ticket with legal confirmation"]
}
],
"superseded_matches": 1,
"duplicates_collapsed": 3
}Where the data comes from
| Your own product data | Documents, tickets, records, comments and attachments already inside your platform — the primary corpus, and the one you have a clear basis to index |
| Customer-connected third-party sources | Shared drives, wikis and repositories the customer authorises through OAuth; the customer grants access, not you |
| Source permission models | Access control lists from each connected system, re-checked at query time rather than trusted from index time |
| Tenant vocabulary | Acronyms, product names and internal jargon, learned per tenant because every company's shorthand is different |
| Query and click logs | Behavioural relevance signals, aggregated per tenant and never pooled across customers without permission |
| Document metadata | Authorship, version, owning team and review dates, which drive freshness and supersession scoring |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Hybrid retrieval combining lexical and dense vector search, because each fails on cases the other handles — exact identifiers and paraphrased questions respectively
- Chunking that respects document structure, so a retrieved passage is a coherent section rather than an arbitrary window
- Permission filtering applied at query time against the source system's current access state, with a documented staleness bound
- Strict per-tenant index isolation, so a bug cannot return one customer's document to another
- Reranking on the top candidate set, where the quality gain is worth the latency cost
- Answer synthesis constrained to retrieved passages, with a refusal when the corpus does not support an answer — an invented answer in a workplace tool is worse than no answer
- Relevance measured against a labelled query set per tenant, with click-through and abandonment tracked as secondary signals
- Connector health monitoring, because a silently failed sync looks exactly like a relevance problem to the person searching
What it changes for the business
Search people trust
Natural-language queries returning the right passage changes search from a last resort into the way customers use your product.
Permission safety
Query-time access checks mean search can span sources without becoming your next security incident.
A platform for assistants
A permission-aware retrieval layer is the prerequisite for any in-product AI assistant you build later.
Content gap visibility
Failed-query reporting tells your customers which documentation does not exist, which is a feature they will pay for.
How it fits into your product
How it embeds
- White-label API behind your own search box, with your brand and domain throughout
- Per-tenant indexes and scoped keys so you can meter and bill search volume per customer
- Search-as-you-type latency budget: cached and warm queries typically in the low hundreds of milliseconds
- Connector framework for the third-party sources your customers ask for most, added over time
- Embeddable result and answer components, or raw JSON for your own interface
- Single-tenant or in-region deployment where customer content cannot leave a jurisdiction
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you guarantee a user never sees a document they should not?
We can enforce permissions at query time against the source system and document the staleness window, which is the honest version of that guarantee. If a permission was revoked thirty seconds ago and the source system has not propagated it, no search layer on earth will know. We design for the shortest practical window, log every access decision, and tell you what the window is rather than claiming zero.
Does this need a vector database and an LLM?
It needs vectors. It does not always need generated answers. Plenty of products are better served by ranked passages with citations than by a synthesised paragraph, and the refusal behaviour on generated answers is harder to get right than the retrieval. We would scope which of the two your customers actually need.
How well does it work on a small corpus?
Retrieval works from the first document. Learned relevance does not — ranking tuned on click behaviour needs traffic, so early tenants get the general model and improve with use. For a tenant with a few hundred documents, the honest answer is that good chunking and metadata matter more than any model choice.
Will it answer questions the documents do not cover?
It should not, and the answer endpoint is built to refuse instead. Constraining synthesis to retrieved passages and returning an explicit no-answer response is a design requirement, not a setting. Tuning that refusal threshold is one of the things we would do with your own labelled queries.
Can we index content our customers connected from third-party systems?
Only within what the customer authorised and what that system's terms allow. The customer grants the connection and can revoke it; you are processing their data on their instruction. Where a connected source's terms restrict derived storage or model training, we design the connector around that rather than ignoring it.
Related blueprints
Document Extraction API
Structured fields pulled from PDFs, scans and forms, built as the extraction layer your ERP, CRM or accounting product embeds.
Web Research API
Structured research answers with source references and freshness metadata, built as the retrieval layer behind your AI agent platform.
Website Change Monitoring API
Alerts when pages your customers are permitted to monitor change — prices, terms, policies, stock or staff listings — as a feature inside your product.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.