Resources
Guides, references, and deep-dives on DDI concepts and OmniTwin's agent-native architecture. Start with a quick start or go straight to the API.
Three ways in — a guided walkthrough, the full API reference, or the CLI if the terminal is home.
Quick Start Guide
Connect your first subnet, run your first discovery scan, and see your IP twin populated in under ten minutes. Covers setup, authentication, and Scout Agent basics.
API Reference
Full REST and GraphQL API documentation with request/response examples, authentication flows, rate limits, and schema definitions for all DDI resources.
CLI Documentation
The omnitwin CLI for scripting, CI pipelines, and
operator workflows. Every command, flag, and output format documented with examples.
Each agent has a defined job, a defined trigger, and a defined scope. Pick the guide for the agent you want to put to work.
Automated network discovery & sensing
Scout continuously scans your subnets using ICMP, ARP, and SNMP to detect active hosts, infer device types, and populate your IP twin without manual entry. Run it on a schedule or trigger it on-demand after a provisioning event.
Day-one onboarding, post-change verification, or any time your twin might lag behind your real network state.
Vendor data translation & migration
The Polyglot reads exports from Infoblox, BlueCat, phpIPAM, and a growing list of DDI vendors, then maps every object — prefix, address, DNS zone, DHCP scope — to the open-standards schema OmniTwin uses internally. No custom scripts needed.
Migrating from a legacy platform, consolidating data from multiple sources, or bootstrapping a new twin from an existing export.
Auto drift detection
Truth Seeker continuously compares the state recorded in your twin against what Scout observes on the live network. When they diverge — a stale record, an undocumented host, a changed assignment — it flags the drift and its severity.
Enable it continuously on any environment where unauthorized or undocumented changes are a compliance or operational risk.
Pre-flight simulation
Before any change touches the network, The Safety Net runs it against a simulation of your twin — checking for conflicts, overlap, scope exhaustion, and zone delegation issues. Changes that fail simulation are blocked from reaching production.
Any planned change to DNS zones, DHCP scopes, or IP allocations — especially in environments with change approval workflows.
Auto-planning for network changes
The Architect takes stated intent — "I need a /24 for the new data center pod, routable from the management VLAN" — and proposes an allocation plan: subnets, VLAN IDs, DNS zones, DHCP scope boundaries. It works within your existing topology and policy constraints.
New site buildouts, data center expansions, cloud VPC designs, or any greenfield addressing work where manual planning is slow and error-prone.
Full closed-loop automation
Once a change is planned (by The Architect or by a human), The Hands stages the execution. The Closer finalizes it — pushing approved changes end-to-end across DNS, DHCP, and IPAM with full audit trail and rollback capability if something goes wrong post-apply.
High-velocity environments where human-in-the-loop execution is the bottleneck, and where a full audit trail and rollback capability are non-negotiable.
DDI stands for DNS, DHCP, and IP Address Management — the three control-plane services that underpin every IP network. Open-standards DDI means those services are built on published RFCs and open protocols rather than proprietary vendor formats. Your data is portable. Your tooling is interoperable. No lock-in.
OmniTwin's schema tracks every IP prefix, address, DNS zone, record, DHCP scope, and lease against the open standard definitions. This means exports from any RFC-compliant system can be imported, and OmniTwin's data can be consumed by any RFC-compliant consumer.
Proprietary IPAM formats create migration friction and API inconsistency. When your DNS server speaks one schema and your IPAM speaks another, reconciliation is a human job — which means drift is a human problem. Open standards collapse that gap: one schema, one source of truth, one set of automation primitives.
A network twin is a live, structured representation of your network's state — every address, every record, every lease — maintained in software and continuously reconciled against the real network. The twin is not a backup or a report. It is the operational surface that agents act on.
OmniTwin's agents don't operate on a separate system and sync back. They operate on the twin directly. When Truth Seeker finds drift, it marks it in the twin. When The Architect plans a change, it plans against the twin. When The Closer executes, it commits to the twin and to the network in the same operation. The twin is the runtime, not the record.
Can't find what you're looking for, or have a question about a specific agent or integration? The team reads every message.
Usually responds within one business day.