Zabbix Frontend Mass Update vs API vs ZbxWizz

Three legitimate ways to change many hosts at once:

Frontend mass update / host wizard
Raw API (Python, Go, curl, …)
ZbxWizz — spreadsheet + templated API calls in the browser

Picking wrong costs either hours of clicking or an outage-shaped Push. Here is a practical comparison for the jobs Zabbix admins actually do: tags, groups, names, enable/disable, light onboarding.

Spreadsheet view of hosts before a bulk change

Side-by-side

Need	Frontend mass update	API script	ZbxWizz
Same field → same value on a short list	Excellent	Overkill	Fine, not required
Different value per row (CSV-driven)	Painful	Natural	Natural
Visual filter + spot-check before write	Limited	DIY logging	Built-in table
Nested JSON (tags, interfaces, macros)	Awkward	Full control	Transform + preview
Reuse next quarter	Click again	If you keep the repo	Saved templates + workbook file
Non-developers on the team	Familiar UI	Barrier	Spreadsheet metaphor
Unattended / CI	No	Yes	No (interactive)
Token & data footprint	Server session	Wherever the script runs	Browser only

Where the frontend shines

Use the UI when:

You selected hosts with the built-in filter and need one change (e.g. all → disabled)
The set is small enough to verify on screen
You do not need a reusable artifact

Stop using the UI when you hear: “we’ll fix the tags from the Excel the app team sent.” That sentence is a CSV workflow wearing a host form costume.

Where raw API scripts shine

Scripts win when:

The operation is identical every night
You need transactions across systems
Changes must be code-reviewed in git
Volume + complexity exceed what you want to babysit in a browser

Cost: auth, pagination, limit foot-guns, and a maintenance tax. Every special case becomes another if branch — or another abandoned gist.

Import from Zabbix is still the official API — params only

Where ZbxWizz fits

ZbxWizz is for interactive, data-shaped campaigns:

Import / CSV → filter → transform per row → preview Push → write selected rows

Examples already covered on this blog:

You still speak host.update / host.create. The difference is the review surface and the ${flds…} / ${cols[…]} templates instead of a for-loop in a file.

Push host.update with per-row fields

Decision tree (short)

< ~20 hosts, identical change → Frontend
Scheduled / multi-system / IaC → Script or Terraform/Ansible
CSV, per-row values, human review, one-off migration → ZbxWizz
Unsure → Export a sample with ZbxWizz, decide whether the rest belongs in git automation

Hybrid patterns that work well

Pattern	How
IaC owns baselines; ZbxWizz cleans drift	Terraform for templates/proxies; workbench for tag debt
Script exports; humans edit; ZbxWizz pushes	Nightly dump → Excel → Import CSV → Push
ZbxWizz prototypes the API payload	Copy the proven Push JSON into a proper job later

CSV import as the bridge from Excel to API

Bottom line

Mass update in the frontend is not “bad” — it is narrow. Raw API is not “overkill” — it is heavy for interactive cleanup. ZbxWizz occupies the middle: official API power, spreadsheet ergonomics, local tokens.

If your last migration lived in Excel anyway, start there: import the sheet, don’t re-type it into the host form.

— Sergiu, Creator of ZbxWizz

← Back to blog