<%NUMBERING1%>.<%NUMBERING2%>.<%NUMBERING3%> PRTG Manual: HTTP API

All calls to the PRTG HTTP API are performed by HTTP GET requests. The URLs consist of a path to the API function and some parameters.

• If you are accessing the API inside your secure LAN, you can simply use HTTP. In insecure environments (for example, when accessing your PRTG server across the internet), you should use HTTPS requests to make sure that your parameters and passwords are encrypted. This way all communication between the PRTG server and your client is SSL-encrypted.

• For every API call, the default limit of items is 500. If you want to receive more items per call, add a count=xxx parameter with enough room for all sensors.
• Authentication with username and passhash (or username and password) must always be included in each request. See section Authentication for more information.
• All data in the GET parameters must be UTF-8 encoded and URL encoded.

Here are two example API calls:

The example URLs consist of the following elements:

• yourserver: the name of your PRTG server.
• /api/table.xml: addresses an API function. Here the function renders a table in Extensible Markup Language (XML) format.
• content=sensors: parameter for additional control. In this case, it includes all sensors in the table.
• columns=sensor: parameter for additional control. In this case, only the names of all sensors are shown in the table.

Authentication

All requests to the API are stateless, which means that there is no multi-step login process of an kind. The authentication with username and passhash (or username and password) must always be included in each request by using the username and passhash (or username and password) parameters.

The example URLs now also contain the credentials for authentication purposes:

• username=myuser&passhash=hash (or password=mypassword)

You can request the passhash for an account with the following API call:

https://yourserver/api/getpasshash.htm?username=myuser&password=mypassword

Make sure that the username and password are URL encoded.

Versioning

Most XML replies from the API contain a <version> field that contains the program version and buildnumber of the server's PRTG installation. Your client must look at this version number and compare it to the version number that was used to develop the client. Do not accept version numbers older (smaller) than this one. You should display a warning to the user (or stop processing) if the version number differs by 0.1 or more (for example, version 18.1 vs. 18.2, or version 17.x vs. 18.x). API conventions or parameters may have changed between versions.

Newer versions of the same major version of PRTG will reply to API calls just as previous versions have.

Error Handling

Depending on whether your API call was processed successfully or not, the PRTG server will reply with the following HTTP status codes:

For 400 error codes, the error XML document will include the error message as follows:

<?xml version="1.0" encoding="UTF-8" ?>
  <prtg>
  <version>18.1.37.10127+</version>
  <error>Sorry, there is no object with the specified id.</error>
  </prtg>

More

Knowledge Base: How can I use the PRTG Application Programming Interface (API)?

• https://kb.paessler.com/en/topic/593

 

Application Programming Interface (API) Definition—Topics

• HTTP API
• Live Data
• Live Graphs
• Historic Data
• Object Manipulation
• Custom Sensors
• Custom Notifications
• Mini Probe API