Integrations

Wired into what you already run.

One direct integration built for Resolvd, and a set of connectors for the RMM, mail, identity, and AI providers a self-hosted helpdesk meets every day. Every one configured in Admin, none of them a SaaS in the loop.

Direct integration Built for Resolvd since v0.10.0

Trove KB, beside the built-in KB or in place of it.

Trove KB is our open-source IT documentation platform: companies, locations, and devices as typed documents, a knowledge base that imports or crawls vendor docs, runbooks with stable step ids, secret fields that point at your vault instead of storing credentials. Resolvd ships its own basic per-project KB. Trove KB is an add-on: switch it on and both run side by side, the local panel and the Trove KB block on every ticket. Or run Replace local KB and Trove KB takes over. Admin's call.

The integration is tailor-made for Resolvd, down to runbook progress keyed by Trove KB step ids and ticket promotions that land as drafts in the right collection. It still runs over Trove KB's public REST API, OpenAPI spec, and HMAC-signed webhooks, so nothing about it is private to Resolvd.

Requirements
Trove KB

v0.1.0 or later, any build with /api/v1/kb/* routes. Free and open source under the AGPL. Docker Compose + Postgres, or a Cloudflare Worker.

API key

read scope, read grants on every collection Resolvd should see, a write grant only on the collection ticket promotions land in.

Identity

Both apps on the same identity provider. Email is the join key for favorites and votes.

Network

Resolvd calls Trove KB's base URL over HTTPS. Trove KB posts webhooks to Resolvd's /api/trove-kb/webhook.

Resolvd

v0.10.0 or later. The built-in KB stays; moving off it is optional.

Full feature list

Browse in Resolvd

A full reader at /kb, not a search box. Users don't need a Trove KB account to read internal docs inside Resolvd.

  • ✓Collections as cards, mapped Internal / Public / Hidden per collection in Admin
  • ✓Category and subcategory rail with counts, built from Trove KB's flat pairs
  • ✓Type filter: Articles vs. Runbooks, plus source format once Trove KB reports it
  • ✓Cards or list, remembered per browser. Sort by title or last modified, cursor paging
  • ✓Search scoped to the collection, or across every mapped collection from /kb
  • ✓Markdown reader at /kb/article/:id with breadcrumbs back into the tree
  • ✓Favorites and helpful votes act for the reader's email, the same row as on the public Trove KB site. /kb lists My favorites

On the ticket

The Trove KB block inside every ticket's Knowledge panel.

  • ✓Linked articles, title and collection snapshotted so the ticket reads right when Trove KB is down
  • ✓Title-based suggestions that search the project's mapped collection first, with an OR fallback when the exact query finds nothing
  • ✓Search-to-link for everything else
  • ✓Resolution draft: an extractive digest always (matched passage, link, runbook steps), plus an AI summary when the caller may use AI Assist
  • ✓Knowledge briefs: Scope with knowledge assembles reported / team / draft / corrections / project context / matched articles into a reviewable form. Build without AI, or rewrite with AI under rules that keep internal articles out of the reply
  • ✓Noise filter: admin-managed regex, literal, or account rules keep SLA notices, moves, merges, and auto-replies out of briefs. Test box included
  • ✓Promote-to-KB upserts a resolved ticket into the project's collection as an internal-only draft keyed resolvd:ticket:
  • ✓Every AI-assisted run is stored with its inputs and output for audit

Runbooks

The checklist lives in Trove KB. The progress lives in Resolvd.

  • ✓A runbook is a Trove KB article with kind: runbook; Trove KB derives steps[] with stable ids on save
  • ✓Resolvd keeps checkbox state per ticket keyed by step id. Hand off mid-incident, the next handler picks up at the unchecked box
  • ✓Step toggles use a Postgres jsonb || merge so concurrent handlers don't clobber each other
  • ✓A step's canned field becomes a 📋 pill that prefills the composer with the canned response, placeholders substituted
  • ✓Recurring ticket schedules can name a runbook and start a run on every fire

Visibility

Resolvd never forwards a user's Trove KB session. One key, Resolvd's own roles.

  • ✓Project handlers (global Admin / Manager / Tech, or a project handler override / Agent flag) see internal + public
  • ✓Everyone else sees public collections only, and only articles Trove KB confirms public
  • ✓audience=public is sent on non-handler reads when Trove KB's OpenAPI declares it; otherwise Resolvd keeps only hits with a public_url
  • ✓Strict mode (default on): a non-handler sees an article only when Trove KB returns it as public
  • ✓Cache keys carry the audience so handler and public views never mix
  • ✓Only Resolvd Admins get Open in Trove KB links into the staff UI

Kept in step

Webhooks first, polling as the floor.

  • ✓POST /api/trove-kb/webhook receives kb.article.upserted / kb.article.archived. Raw body, X-Trove-Signature HMAC-SHA256 checked in constant time, secret stored encrypted
  • ✓60 s result cache, 12 s request timeout. Errors never carry the key
  • ✓Collection sync hourly, on Test connection, and on demand. New public collections auto-map Public when the toggle is on; Hidden is never undone
  • ✓Nightly snapshot refreshes titles and collection names on links and runbook runs
  • ✓Feature probe reads Trove KB's OpenAPI every five minutes. Favorites, votes, and audience light up when declared
  • ✓Check for changes now polls on demand from Admin

Admin + migration

Admin → Integrations → Trove KB. Five fields, one key. Side by side with the local KB, or replacing it.

  • ✓Base URL, public site URL, API key (encrypted at rest under RESOLVD_MASTER_KEY), enabled, strict public mode, auto-map public, webhook secret
  • ✓Test connection pulls the collection list; map each Internal / Public / Hidden
  • ✓Local KB checkbox: keep the built-in KB beside Trove KB, or switch it off and back on without migrating
  • ✓Project ↔ collection in Admin → AI Assist → Project contexts: the collection each project searches first and promotes into
  • ✓Optional. Replace local KB shows the plan first (twins by external_id, links, runs, step coverage), then copies links, re-keys runbook progress to Trove KB step ids, archives local articles, and turns the local KB off
  • ✓Local tables are kept one release for rollback. An export script turns BlockNote JSON into Markdown + frontmatter in Trove KB's import layout
Resolvd → Trove KB

Resolvd reads over /api/v1/kb/* with one bearer key: collections, search, articles with steps, favorites and votes for a named reader, and one upsert route for Promote-to-KB. Trove KB posts back over two webhook events. The surface Resolvd exposes to its own frontend:

GET    /api/trove-kb/status
GET    /api/trove-kb/collections[/:id]
GET    /api/trove-kb/articles[/:id]      # ?collection_id ?category ?kind ?sort ?cursor
GET    /api/trove-kb/search?q=
GET    /api/trove-kb/runbooks
GET    /api/trove-kb/tickets/:id/links | suggestions
POST   /api/trove-kb/tickets/:id/resolution-draft
POST   /api/trove-kb/tickets/:id/assist/brief | compose
POST   /api/trove-kb/tickets/:id/promote
GET    /api/trove-kb/tickets/:id/runbook-runs
POST   /api/trove-kb/webhook             # Trove KB → Resolvd, HMAC-SHA256
Who owns what
Trove KB

Trove KB articles, runbooks, categories, collections, public vs. internal

Trove KB

Authoring, imports, vendor-doc crawls, favorites, helpful votes

Your vault

Credentials. Trove KB stores none; secret fields reference your vault

Resolvd

Built-in per-project articles and runbooks, while the local KB stays on

Resolvd

Which articles and runbooks are linked to a ticket

Resolvd

Runbook step progress per ticket

Resolvd

Resolution summaries, knowledge briefs, AI drafts and their audit log

Resolvd

Who in Resolvd sees internal vs. public content

Resolvd never sees a secret through the integration. Neither does an AI assistant reading Trove KB over its MCP endpoint.

Connectors

Everything else Resolvd talks to.

Configured in Admin, credentials encrypted at rest, each one documented on its feature page.

Action1*

RMM connector

REST poll with OAuth2 client credentials. Feeds alerts, inventory endpoints, installed software, security posture (patches, vulnerabilities, reboot required), and companies. Per-source token-bucket rate limit, custom-attribute slots mapped to asset columns or custom fields.

Admin → Alert sources Learn more

Zabbix

Monitoring adapter

Webhook intake for problem fire / clear, optional REST backfill for historical context, hostgroup → project routing per source.

Admin → Alert sources Learn more

Generic webhook

Alert adapter

Any alert source that can POST JSON. A tabular field-map editor turns its payload into severity, host, title, and clear events, then the same rules engine decides promote / notify-only / ignore.

Admin → Alert sources Learn more

Microsoft 365 (Graph)

Email backend

OAuth through the same Entra app registration that powers SSO. Inbox monitoring over Graph /subscriptions with clientState validation, self-healing renewals, outbound send from a named mailbox. Refresh tokens encrypted under the workspace key.

Admin → Email backends Learn more

Gmail API

Email backend

OAuth inbox + send for Google Workspace. Same inbound pipeline: dedup, signature and reply-marker stripping, banner-strip presets, project-scoped mailboxes.

Admin → Email backends Learn more

SMTP

Email backend

For self-hosters where OAuth isn't an option. STARTTLS with app passwords. Outbound notifications, digests, and vendor mail.

Admin → Email backends Learn more

Microsoft Entra ID

Identity

SSO via MSAL, directory lookup for user auto-provision and UPN matching, deep-link return after sign-in. TOTP MFA per role on top.

Admin → Authentication Learn more

Google OAuth

Identity

SSO for Google Workspace tenants with directory-backed auto-provision. Local accounts with Argon2id remain available alongside either provider.

Admin → Authentication Learn more

OpenAI · Anthropic · Ollama

AI providers

Bring your own key for AI Assist: OpenAI and OpenAI-compatible endpoints (Azure OpenAI, OpenRouter, vLLM, LM Studio), Anthropic's Messages API, or a local Ollama with no key at all. Org key with lock, or per-user BYOK.

Admin → AI Assist Learn more

Zebra / ZPL label printers

Hardware

Raw TCP to port 9100. Asset and consumable labels with a QR that scans back to the Resolvd row; consumables allocate stock on print.

Admin → Label printer Learn more

Web Push (VAPID)

Browser

Browser push through a service worker, one of the three channels in the per-event notification matrix beside in-app and email.

Notification settings
Bring your own

Not on the list? Two doors in.

Alert adapters live in a registry. Each one declares a credentialsSchema that the Admin add-source form renders on its own, so onboarding another RMM with a webhook-flavored alert format is a registry entry, not a UI change.

Until then, the generic webhook adapter takes any JSON payload and a field map. Rules, dedup, promotion, and the dashboard widget work the same as for a named vendor.

# services/integrations/registry.js
id: "your-rmm"
mode: "webhook" | "rest_poll"
credentialsSchema:
- name: api_token kind: secret required: true
map: payload → severity · host · title · clear

Plug it in.

Admin → Integrations. Trove KB takes a URL and a key; the rest take a credential and a toggle.

* The Action1 integration is an independent community project and is not affiliated with, endorsed by, sponsored by, or supported by Action1 Corporation. Action1 has not reviewed, tested, certified, or audited this integration for security, performance, or compliance purposes and is not responsible for its operation, availability, or use. “Action1” is a trademark of Action1 Corporation and is used solely to identify compatibility with the Action1 platform.