> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Zabbix API

> Read Zabbix hosts, problems, latest values and history; acknowledge and close problems, set maintenance, run scripts and change monitoring — each change follows the approval settings you give it

An agent with this tool answers a monitoring ticket from your Zabbix data: which host it is about, whether Zabbix can still reach it, which problems are open on it, and what its values looked like when the problem started.

<Info>
  Automatically enabled when you configure Zabbix permissions in your agent workflow. No manual toggle needed.
</Info>

## What It Does

* Find the host by visible or technical name, IP address or DNS name, or among a client's host groups or tags
* Read the host's availability per interface, its open problems with their severity and acknowledgements, and the trigger behind each problem
* Tell a host that is down from a stopped Zabbix agent or an offline proxy
* Read any item's latest value, history and hourly trend, such as CPU, memory, disk and ping
* Acknowledge, comment on, close, suppress or change the severity of a problem, with the ticket number in the message
* Put a host or host group in maintenance for planned work
* Run a script you defined in Zabbix on a host, such as a ping or a service restart
* Change hosts, host groups, templates, items, triggers, macros, users and other Zabbix settings, with the access and approvals you choose

The agent calls Zabbix through the [Vendor API](/agents/tools/vendor-api) tool, with `zabbix` as the vendor id. [Sandbox](/agents/tools/built-in/sandbox) scripts can call Zabbix too, under the same permissions.

## Permission Groups

| Group | What it covers |
| - | - |
| **Problems and Events** | Current problems, events and the alerts Zabbix sent. Write acknowledges, comments on, closes, suppresses or changes the severity of a problem |
| **Hosts** | Hosts, host groups and host interfaces. Deleting a host always requires technician approval |
| **History and Trends** | Collected values and hourly trends. Write sends values to trapper items |
| **Maintenance** | Maintenance periods |
| **Scripts** | Global scripts: read, run on a host or for an event, create, change and delete |
| **Items, Triggers and Discovery** | Items, triggers, graphs, web scenarios, low-level discovery and their prototypes, host macros, value maps and "check now" |
| **Templates** | Templates, template groups and template dashboards |
| **Actions and Media Types** | Actions, media types and event correlation |
| **Dashboards, Maps and Reports** | Dashboards, maps, images, icon maps and scheduled reports |
| **Services and SLAs** | Business services and SLAs |
| **Network Discovery and Proxies** | Network discovery rules and results, proxies, proxy groups and autoregistration |
| **Users and Access** | Users, user groups, roles, API tokens, user directories, MFA and authentication. The changes listed under "Changes that always ask a technician" below always require technician approval |
| **Administration** | Global settings, housekeeping, modules, regular expressions, connectors, global macros, the audit log and HA nodes |

Every group can be Disabled, Read Only or Read/Write. Neo never sends these methods: `user.login`, `user.logout` and `user.checkAuthentication` (Neo uses the API token), `token.create` and `token.generate` (a new token works only once its secret is generated, and Neo never reads a secret), `history.clear` (it destroys data), and `configuration.export`, `configuration.import` and `configuration.importcompare` (an export can carry passwords, and an import makes many changes at once). Neo removes the fields Zabbix keeps credentials in (passwords, SNMP communities and passphrases, pre-shared keys, credential headers, HTTP request bodies, and the user name and password in a URL) from every answer; text typed elsewhere, such as a script's command or a text macro, reaches the agent as written.

## Access Profiles

<AccordionGroup>
  <Accordion title="Read Only">
    Every group Read Only. The agent reads, and never changes anything.
  </Accordion>

  <Accordion title="Helpdesk">
    Problems and Events is Read/Write without approval. Maintenance and Scripts are Read/Write with technician approval. Everything else is Read Only.
  </Accordion>

  <Accordion title="IT Admin">
    Every group Read/Write. Scripts, Actions and Media Types, Users and Access, and Administration require technician approval, and so does deleting a host.
  </Accordion>

  <Accordion title="Full Automation">
    Every group Read/Write without approval, except the changes below, which still require technician approval.
  </Accordion>
</AccordionGroup>

## Changes that always ask a technician

These require technician approval under every access profile, whatever the group's own approval setting:

* Changing authentication settings (HTTP, LDAP and SAML sign-in, the default sign-in method, the password policy).
* Creating, changing, testing or deleting an LDAP or SAML user directory.
* Creating, changing or deleting an MFA method.
* Creating, changing or deleting a user role or a user group.
* Creating, deleting or provisioning a user from LDAP, or changing a user's role, user groups or user directory. Disabling a user means moving them to a disabled user group, so it asks too.
* Resetting a user's MFA.
* Changing or deleting an API token.
* Deleting a host, which removes its collected history.
* Any change that stores a credential: a password, a secret macro, a credential header or parameter, the user name and password in a URL, or an HTTP agent's request body.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.