Any PSA. Any assistant. Never a secret.
Trove KB has no coupling to any particular ticketing system. It has a REST API that does everything the app does, webhooks signed with a key you hold, a lookup that turns a PSA's client id into that client's documentation, and a Model Context Protocol endpoint on the same keys.
One spec, generated from the validators.
/api/v1, JSON, a bearer API key with read, write, admin, and reactions scopes, cursor pagination. The OpenAPI document at /api/v1/openapi.json is built from the same Zod schemas the endpoints validate with, so it cannot drift.
A key is created with every company or a named set. Lists omit what it may not see; a single record it may not see answers 404, the same as a missing id, so a key cannot be used to learn which companies exist.
curl -H "Authorization: Bearer $TROVE_KEY" \ "https://docs.example.com/api/v1/lookup?system=halopsa&entity=company&external_id=123" # → the company, its locations, and a summary of its documents
Create, read, update. Documents return resolved values (option labels, linked titles, rendered markdown) beside the raw ids.
Templates with their fields; shared lists, with POST to add an option exactly as the + does.
The history, as the app shows it.
The same tsvector search, scoped to the key's companies.
Map a PSA's ids to companies and documents, then look a client up by that id, or deep link without the API at all.
Collections, search, articles with steps, upsert and archive under an external id, grants, favorites and votes for a named reader.
Metadata-only item lists and, with the secrets:reveal scope, reveal and TOTP. Audited, no-store.
A ticket jumps straight to its client.
The main use case: a ticket in HaloPSA, Autotask, ConnectWise, or your own tracker needs to show that client's docs. Upsert an external ref once, mapping their id to the company, then either call /lookup from the integration or embed a deep link that needs no API at all:
PUT /api/v1/external-refs { "entity": "company", "entity_id": "…", "system": "halopsa", "external_id": "123" } # then, from the ticket: https://docs.example.com/go/halopsa/company/123
Signed. Retried.
Every delivery carries X-Trove-Signature: sha256=…, an HMAC over the raw body with the secret shown once when the webhook was made, plus an event name and a delivery id. A worker in the app container retries with exponential backoff up to eight times; on a Worker deployment a Cron Trigger does the same pass.
"What's the firewall admin URL for this client?" Answered from the docs.
POST /api/mcp, Streamable HTTP, the same API keys as REST, so access is granted and revoked in one place and inherits the key's companies. Point Claude Code, Claude Desktop, or any MCP client at it.
claude mcp add --transport http trove-kb \ https://docs.example.com/api/mcp \ --header "Authorization: Bearer $TROVE_KEY"
No assistant can read a credential.
Secret fields are stripped from every MCP response, and there is deliberately no reveal tool. Revealing a credential stays a decision a person makes in Trove KB, where it is audited. Nothing exposed over MCP can change client documentation.
Documentation, secrets redacted.
The hierarchy and the templates.
The knowledge base, one matching passage per result, long articles in chunks.
Only for a key granted write on a collection, and only there.
The knowledge base behind the ticket.
Resolvd, our issue tracker, uses Trove KB as its knowledge base outright: one place for the vendor manuals, the runbooks, and the client documentation, instead of a second set of articles inside the ticketing system.
A ticket shows the client's documentation through the lookup, surfaces the articles and runbooks that match it, and tracks runbook progress by step id on the ticket while the runbook itself stays here. When a tech asks, Resolvd's AI assist drafts a reply or a resolution from those articles and from past resolutions, with the knowledge base as its source rather than its guess.
Running in production today over the same REST API and webhooks described on this page. Nothing about it is private to Resolvd: the lookup, runbook step ids, the knowledge base API and MCP tools, and the webhooks are open to any other ticketing system that wants the same.
GET /lookup by the PSA's own client id, and /go/… deep links from the ticket.
search_kb and GET /kb/search ranked against the ticket; runbooks tracked per ticket by step id, progress kept on Resolvd's side.
A resolved ticket's fix can be written up as an article through PUT /kb/collections/:id/articles/:external_id, under a key granted write on that collection.
Resolvd's bring-your-own-key AI assist drafts from the matched articles, runbooks, and prior resolutions. Trove KB stays the source; secrets are never in the context.
kb.article.upserted and kb.article.archived webhooks tell Resolvd what changed.
Wire it to what you already run.
The API docs are in the docs section, and the OpenAPI spec is on every instance.