Using NetBox Custom Fields to Capture Vendor-Specific Hardware Attributes

When the built‑in fields fall short

NetBox models devices, interfaces, and virtual machines with a fixed set of attributes. When you need to store vendor‑specific data—such as a service tag, warranty end date, or a custom status flag—there is no column in the core tables. Editing the database schema or keeping a separate spreadsheet introduces drift and maintenance overhead.

What Custom Fields provide

Custom Fields let administrators define additional attributes that attach to existing NetBox objects through the UI or API. You choose a name, type (text, integer, boolean, date, selection), and optionally scope the field to one or more object types (e.g., only Devices). Validation rules such as Required or a list of Choices can be enforced, keeping data consistent across teams.

Worked example: tracking a service tag on devices

Suppose your hardware vendor supplies a unique service tag that you want to record for every device.

1. Log in to NetBox as a user with the Customization permission.
2. Go to Customization → Custom Fields and click Add Custom Field.
3. Enter Service Tag as the field name, select Text as the type, and check the Device model under "Content types".
4. Optionally mark the field as Required if every device must have a tag.
5. Save the field.

The new field now appears on the Edit and Create forms for any Device.

To verify that the field is exposed via the REST API, run the following command from a workstation that can reach your NetBox instance (replace placeholders with your actual values):

curl -s -H "Authorization: Token $NETBOX_TOKEN" https://netbox.example.com/api/dcim/devices/?limit=1 | python3 -m json.tool | grep -A 5 ""custom_fields""

Where to run: any shell with curl and network access to the NetBox server.

Required permissions: an API token with at least read access to the DCIM endpoint; the token’s user must be able to view custom fields (typically an admin or a role granted the customization.view_customfield permission).

Meaningful placeholder: $NETBOX_TOKEN is your personal API token; https://netbox.example.com is the base URL of your NetBox installation.

Expected check: the JSON output should contain a custom_fields object with a key named service_tag (NetBox converts the field name to lower‑case snake_case) and the value you entered for the selected device.

Relevant risk: if you add this field to thousands of devices and frequently filter or sort on it in large API lists, query latency may increase unless the underlying column is indexed.

Trade‑offs and practical limits

• Performance at scale: Each custom field adds a column to the underlying model’s table. Very many fields or frequent filtering on unindexed fields can slow down API responses. Consider adding a database index via NetBox’s EXTRA_INDEXES setting or limiting the field to the objects that truly need it.
• No native relationships: A custom field cannot reference another NetBox object (e.g., link a device to a custom contract). For relational data you must either model the relationship with existing NetBox objects (like using the Contracts app) or store an identifier and resolve it outside NetBox.
• Changing field type: Altering a field’s type after data has been stored may cause validation errors or data loss. Plan the type up front, or create a new field and migrate data via a script before removing the old one.

Actionable verification steps

1. Create a test device (or use an existing one) and populate the Service Tag field via the UI.
2. Retrieve the device through the API as shown above and verify the service_tag appears with the correct value.
3. Time a request that lists 500 devices with and without the filter ?service_tag=abc123 to observe any latency difference; if the delay is noticeable, discuss adding an index with your database administrator.
4. Document the field’s purpose and any validation rules in your internal NetBox run‑book so future administrators know why it exists.

By using Custom Fields you keep the core NetBox schema intact while gaining a structured, API‑accessible way to capture the vendor‑specific attributes your operations team needs.