Skip to content
Guides & References

Integrations guides

How rConfig connects to your tooling: Device Sync from inventory and monitoring sources, one-off data imports, inventory enrichment and webhooks.

IntegrationsUpdated
On this page

Integrations guides

rConfig sits between the tools that know which devices exist and the people who need to hear when those devices change. Devices come in from a source of truth, a monitoring platform or an older configuration tool. Events go out to chat channels, ticketing and automation. This page explains the moving parts, how they differ and which to use when. The step-by-step setup stays in the main docs, starting with the Device Sync V2 overview.

Three directions of flow

Flow Feature Runs Typical use
Devices in, continuously Device Sync V2 On a schedule, as a Scheduled Task Keep rConfig’s inventory in step with NetBox, Zabbix and similar
Devices in, once Data Import tools From the command line, when you choose Move off Oxidized, RANCID, NetMRI or SolarWinds NCM
Events out Webhook notifications The moment an event happens Post config changes, failures and compliance results to chat or automation

A fourth feature, inventory enrichment, works on devices already in rConfig. It is covered below.

Device Sync treats another platform as the authority on which devices exist. Each configured source is an integration instance with its own connection, filters, default Device Profile and schedule.

Supported sources

Kind Platforms Status in the docs
Source of truth NetBox, Nautobot Field tested
Source of truth Infrahub Lab tested
Monitoring Zabbix, Statseeker, Checkmk Field tested
Monitoring PRTG, Tufin AKIPS, LibreNMS, OpenNMS Lab tested
Monitoring Observium Unverified

LibreNMS, Observium and OpenNMS arrived in V8.4.2. Field tested drivers have run against live customer environments; lab tested ones have only run in the rConfig lab. The V1 Device Sync engine is deprecated from V8.2.0 and supported only through the V8.2.x line.

How a run decides what to do

Every driver uses the same six-stage pipeline: validate_setup, extract, canonicalize, reconcile, decide, apply. The design choice that matters most is the split between the last two stages:

  • A preview run goes all the way through decide, so you see exactly what would be created, updated, skipped or flagged, without writing anything.
  • An apply run commits those decisions.

Reconciliation matches each upstream record against existing rConfig devices using identity fingerprints (external ID, hostname plus primary IP, serial) and gives it a tier: strong, medium, ambiguous or none. rConfig does not guess on the uncertain tiers. Ambiguous and medium matches that need review are parked in Problem Devices for a person to resolve.

When a device disappears upstream, the default missing-upstream policy disables the link but leaves the device in rConfig.

Device Profiles: mapping without per-host tags

A Device Profile bundles what rConfig needs to back up a device: template, vendor, category, credential set, and optionally an SNMP group, a Vector agent (with Vector Server) and default tags. The upstream platform names the profile by slug, so engineers maintain one tag or custom field per host instead of several.

How strictly the profile is required depends on the source:

Source Profile reference If missing
Zabbix rconfig::device_profile tag Rejected by default, listed in Problem Devices
Checkmk Host label Required by default
NetBox, Nautobot Custom field Advisory: the device is still created, without profile defaults
Tufin AKIPS Not exposed by AKIPS Every device uses the instance’s default profile

One source or several

A single instance per platform is the simplest layout. Several instances make sense when one upstream holds devices that need different handling. The AKIPS guide, for example, splits the integration into instances scoped by query template so each group of devices gets its own default profile. Every instance is scheduled as its own Integration V2 Job task, and each keeps its own links between upstream IDs and rConfig devices.

If two sources can report the same device, run a preview of each before applying and check the reconciliation tiers and Problem Devices. For NetBox, the opt-in Match Devices pass (V8.4.0+) can resolve a renamed device against the existing rConfig record instead of creating a duplicate.

Data Import: a one-off migration

The import tools for Oxidized, RANCID, NetMRI and SolarWinds NCM are command-line utilities, and they follow the same three main steps: map the old tool’s device types to rConfig templates, vendors and categories, load the devices into an import-ready file, then bulk import.

Choose When
Device Sync The other platform stays in service and remains the authority on the device list
Data Import You are leaving the other tool, or bringing its inventory over once

Imports move inventory, not history. The RANCID tool, for example, leaves configurations already collected in the old version control system, creates no backup tasks and does not modify the RANCID installation. NetMRI can also be imported while it stays live, to evaluate rConfig alongside it.

Enriching devices already in rConfig

Once devices are in, two features fill in properties during backups:

  • SNMP polling collects values such as serial numbers, software versions and uptime over SNMP.
  • Configuration property parsing extracts values from command output with regular expressions. Use it where SNMP is disabled or does not expose what you need.

Extracted properties appear in inventory reports, and SNMP polling data can be exported through the API or reports to feed a CMDB or ITSM platform.

Notifications: events out

From V8.4.1, webhooks are the recommended way to send rConfig events anywhere. One webhook can post in Slack, Microsoft Teams, Discord or Google Chat format, or as generic JSON for your own automation. Each one subscribes to its own events and minimum severity, so on-call and change-log channels can receive different streams.

Points that shape the design:

  • Events cover the whole platform: config changes and downloads, device connection failures, Vector agent down and recovered, imports, tasks, compliance, authentication setting changes and health checks.
  • State-change events fire once. Per-device compliance failures, Vector agent outages and health check failures send one event when the state changes, not one per run.
  • Delivery is queued and retried. Horizon workers must be running. Each delivery is tried up to four times, and a webhook that fails 10 times in a row is switched off and raises a system.notification_error event.
  • Generic JSON is signed. An HMAC-SHA256 signature header lets the receiver check the payload came from rConfig.
  • Webhooks are system-wide. An admin configures them once. Each user’s own email and in-app preferences are separate.

The older .env-based Slack and Microsoft Teams integrations still work, but they cover two event types and one channel each, and are legacy.

Type to search.