NetBox Custom Fields and Custom Links for Automation

Out of the box NetBox models the physical and logical network well, but every environment has data it does not ship with: warranty end dates, vendor contract IDs, PoE budgets, compliance tags, the name of the person who owns a site. Custom fields solve that without forking the application, and because they are stored as JSON and exposed through the REST API, GraphQL and CSV exports, they become immediately useful for automation instead of being documentation nobody reads. This article covers field types, the API filter syntax, and the Jinja2-powered custom links that turn NetBox into an operations console.

Where Custom Fields Live

Custom fields are managed under Customization → Custom Fields. They attach to any object type — devices, sites, racks, IP addresses — and support filtering, appear in the UI, and are returned by the API. Available types cover the practical cases:

• Text / Long text — serial numbers, notes, configuration snippets.
• Integer — power draw in watts, PoE budget.
• Date / DateTime — end-of-life, warranty expiry.
• Boolean — flags such as "monitored" or "in maintenance".
• URL — links to datasheets.
• Select / Multi-select — constrained values such as a support tier.

Use Select or Multi-select wherever a value must be consistent. A free-text field that should contain "Gold", "Silver" or "Bronze" will inevitably contain "gold", "Gold " and "GOLD" within a month, and every automation that keys on it breaks.

Fields can also carry validation: a regular expression, minimax bounds, or a JSON schema. Enforcing a format at entry time is far cheaper than cleaning it up later.

name,label,type,object_types,required,validation_regex,group_name
eol_date,EOL Date,date,dcim.device,false,,Lifecycle
support_contract,Support Contract ID,text,dcim.device,false,^SUP-[0-9]{6}$,Support
site_contact,Site Contact,text,dcim.site,false,,Operations

That CSV can be pasted straight into Custom Fields → Import, which is the fastest way to stand up a consistent field set across a large inventory.

Querying Custom Fields Through the API

The critical detail for automation is the cf_ prefix. Custom fields are filterable with the normal lookup suffixes:

GET /api/dcim/devices/?cf_eol_date__lte=2026-01-01
GET /api/dcim/devices/?cf_support_contract=SUP-004521
GET /api/dcim/devices/?cf_support_tier=Gold

That first query is a hardware refresh report, generated on demand, with no export step. It is the single most useful thing custom fields enable: asset lifecycle questions that used to require a spreadsheet now take one API call.

Custom Links: Jinja2 Into Other Systems

Custom links render as buttons on an object's page and generate a URL from the object's own data using Jinja2. They live under Customization → Custom Links.

name,object_types,link_text,link_url,new_window
device_zabbix,dcim.device,Zabbix Host,https://zabbix.example.com/host/{{ obj.name | lower }},true
device_noc_ticket,dcim.device,Open NOC Ticket,https://noc.example.com/ticket/{{ object.serial }},true
site_dashboard,dcim.site,Site Dashboard,https://dash.example.com/site/{{ object.serial }},true

Two small details matter. First, agree internally on whether you reference obj or object in the templates — both appear in real deployments and inconsistent usage is a common source of broken buttons. Second, custom links only build the URL; they do not call the API. If you need bidirectional automation, that is what webhooks and event rules are for: they fire on object create, update or delete and POST a rendered payload to an external endpoint.

Export Templates

Export templates let you render a queryset into any text format with Jinja2: XML inventory for a monitoring tool, a router configuration stub, a vendor-specific CSV. Combined with the config contexts feature, which merges arbitrary JSON onto devices or VMs by matching on site, role or platform, this is how NetBox drives configuration generation rather than just recording it.

Practical Guidance

• Keep custom fields few and meaningful. Twenty fields that nobody fills in are worse than five that are enforced.
• Set the search weight on fields you actually query; it affects UI search relevance.
• Control visibility and editability per field — some fields should be read-only in the UI and updated only by automation through the API.
• Document the cf_ filter name for every field you expect automation to use; the label shown in the UI is not the API parameter.

Related on this site: NetBox IPAM Guide: Model Prefixes, VLANs and IP Addresses for the address-management core, Nautobot Source of Truth: Docker Deployment Guide if you need a NetBox-derived platform with more plugin surface, and GitOps for Network Configuration: Pipeline Design for wiring the source of truth into a configuration pipeline.

原文链接：https://netodata.io/netbox-custom-fields-relationships