Skip to content

ProofQL documentation

ProofQL turns a business’s reviews into a semantically searchable corpus. Your implants page shows implant reviews, your pricing page shows reviews about value, your location page shows the ones that mention parking. Nothing is tagged by hand; matching is by meaning, and when nothing matches well enough the result is empty rather than wrong.

GET /v1/query?key=pq_pk_live_…&q=dental+implants&limit=3
{
"results": [
{
"score": 0.91,
"excerpt": "Dr. Patel did my implant and I honestly forgot it wasn't my own tooth within a week.",
"excerpt_id": "…",
"highlight": { "start": 26, "end": 110 },
"review": { "id": "…", "rating": 5, "author_name": "Marcus T.", "source": "google", "occurred_at": "2026-03-14T18:20:00.000Z", "url": "https://maps.google.com/…", "author_avatar_url": null, "metadata": {} }
}
],
"took_ms": 12,
"cached": false,
"badge": true
}
  1. Ingest. Reviews arrive through the push API, a CSV upload in the dashboard, or (soon) the Google connector, in one normalized shape.
  2. Index. Every review is embedded whole, every sentence of it is embedded on its own, and longer reviews also get sentence-window excerpts, so a review that covers four topics matches four queries and the highlight lands on the one sentence that answered. Vectors and a full-text index live in Postgres. No LLM touches your reviews.
  3. Serve. /v1/query runs hybrid search, applies a relevance floor and your publication policy in one SQL statement, and returns ranked excerpts with their parent reviews. The snippet renders them; the hosted demo shows it on a page.

ProofQL is in pre-launch: the API, pipeline, snippet, dashboard and these docs are built and deployed to a preview environment; public signup opens once the launch checklist is done. The repository is public, so the roadmap and the backlog are too: roadmap · open issues. Questions go to support@proofql.dev.