Blog from June, 2019

I often utilise Postman to query the Open-AudIT API when developing.

Just using a browser, it's difficult to send anything other than a GET request - but Postman makes it simple to send a POST, PATCH or DELETE as required.

You can get it from for Windows, Mac and Linux.

Install and start Postman. You can elect to create an account or not. You can also elect to create a new item using the wizard, or just close the modal and jump in. Let's do that (smile)

For the below, my Open-AudIT server is running on You should substitute the IP address of your Open-AudIT server.


First you need to make a post to /login to get a cookie. Set the dropdown to POST and the URL to Set the header Accept to application/json. Set the Body to form-data and provide the username and password keys, with values as appropriate for your installation. By default it will look as below.  Now click the Send button.

You should see the JSON result saying you have been authenticated.


Once that's done, it's time to request some data. Make a GET request to and you should get a JSON response containing a list of devices. You can see the start of the JSON in the screenshot below.


What about changing the attribute of an item? Not too difficult. You'll need the ID of the device you want to change, along with the attribute name from the database and an access token.

Access tokens are generated with every request type. You will need a token when submitting a POST or PATCH request. Run another query (a GET is fine, even if no items are returned) and parse the JSON reponse for meta → access_token. Include this in your request body as below.

Attribute names are visible in the application by going to menu → Admin → Database → List Tables and clicking on the "system" table. Let's change the description for our device with ID 14.

You'll need to create a JSON object and assign it to the "data" item to do this. It's not too difficult. Your JSON object should look like below (formatted and indented for easy reading).

	"data": {
        "access_token": "bbc0c85653fdc4b83d108cba7641bfcbbc77586dfb8f32d08973770a90fe",
		"id": "14",
		"type": "devices",
		"attributes": {
			"description": "My New Description"

It looks worse than it is. Normally you would use code to do this, so it's a simple two line conversion. Because we're using Postman, we'll have to do it ourselves. A useful site is

So now you have your payload, let's send it to Open-AudIT. Make a new PATCH request and use the URL Supply the data attribute in the body → x-www-form-urlencoded section and hit Send. You should see the request as below.


Deleting an item is the even easier. Let's delete an Org. In this case, our Org with ID 2. Make a new DELETE request to That's it - easy (smile)

And if we want to read a specific entry, it's just a GET request. Let's get our default Org - ID 1. Just make a GET to


What about running a query? What's the HTTP verb used to EXECUTE something? There is none (sad) But we'll make do by supplying /execute after the ID. So to execute a query, make a GET request to To execute a discovery, task or baseline, use the same format - ID/execute.


If we want to create a new item, use a http verb of POST^ and include an  access token. An access token is generated with every request (except logon) and any of the last 20 (by default, settable in the configuration) will be accepted. You should always aim to use the last access token issued.

Remember we always receive the result in JSON as that is in our request header. We could receive it as HTML is we want - just remove that header item. Maybe more useful is a CSV output. Remove the Accept header and change the URL for a GET to Done - CSV output you can copy and paste into Excel.

It really is that simple. The only one to watch is the PATCH request, because you have to create your own JSON. Just about everything else is quite discoverable. Make sure you check the pages for Collections which detail the request formats. And don't forget The Open-AudIT API page as well.

That makes for a simple and easy way to test the Open-AudIT API.

For more examples, please our new page API Examples for Postman

Onwards and upwards.

Mark Unwin.

With the release of Open-AudIT 3.1.0 we have massively expanded the options around keeping and processing data from devices.

SubSections of a device within Open-AudIT refers to the many tables that hold specific data types - software, netstat ports, processors, memory, disks, users, groups, etc, etc.

These options exist (for now at least) in the Configuration of Open-AudIT. The items of interest are create_change_log* . and delete_noncurrent*.

We previously had these options for a couple of select couple of Subsections, but have expanded these to cover every subsection.

Create Change Logs

The items named create_change_log_* use the database table names to specify which subsection they apply to - so create_change_log_software and create_change_log_memory are both valid examples. You can override ALL items by setting create_change_log to "n" - this will stop any change logs being generated, regardless of the individual table setting. So if a device has a piece of software added (for example), a correspond change log would not be inserted if create_change_log_software was set to "n". This is set to "y" by default. This matches how Open-AudIT has always worked.

Special Items

We have also introduced three special configuration items for Netstat Ports. Because ports above 1024 are mostly designed to be dynamic, we now provide three options to keeping this data. create_change_log_netstat_registered, create_change_log_netstat_well_known and create_change_log_netstat_dynamic. These options correspond to the ports 0-1023, 1024-49151 and 49152-65535.See In particular, Windows DNS servers open a LOT of ports high in the range that are (in my opinion) silly to keep track of, see here and here. By default, only create_change_log_netstat_registered is set to "y". We may add to these options in the future for other subsection, if required.

Delete NonCurrent Items

Along similar lines, the configuration items for delete_noncurrent* use the database table names to specify which subsection they apply to. If set to "y", then no historical entries will be kept for that table, only the "current" items as at the last audit (or discovery). Again, these individual items can be overridden by the global "delete_noncurrent" item. If set to "y", it will remove all noncurrent items from all tables. This is set to "n" by default. This matches how Open-AudIT has always worked.

Hopefully these options provide some customisability for you to only keep the data you actually need.

Onwards and upwards.

Mark Unwin.

Open-AudIT 3.1.0 released

After some extensive code rework, Open-AudIT 3.1.0 has been released for both Linux and Windows.

The Release Notes for Open-AudIT v3.1.0 provide specific details, but at a high level we've been changing the codebase to allow us to provide Open-AudIT Cloud in the near future. A hosted version of Open-AudIT that is always up to date, gets the latest code before regular releases, gets patches and bug fixies straight away and minimises the amount of infrastructure on premise required to get Open-AudIT up and running.

There have also been improvements around The Default Network Address, example device data, audit subsection processing, logging improvements, bug fixes and more.

I hope you find Open-AudIT as useful as I do.

Mark Unwin.

The Default Network Address

With the new release of Open-AudIT 3.1.0, we no longer require the configuration item "default"network"address" to be set for Discoveries. It is still required for the "Audit My PC" functionality, but we hope to minimise this dependance going forward as well.

Why was Default Network Address required?

Initially when we ran a discovery, on both Linux and Windows, we ran the audit script in such a way that it needed to know where to submit it's result. What URL should it use - hence the requirement for the configuration item. A while back now we changed how Discoveries ran under Linux, removing this requirement.


Linux discoveries send the audit script to the target, run it with a flag of "submit_online = n" and "create_file = w". So do not submit the result to the server, create a file and output the filename to the console. The server waits for the script to finish and captures the console output. It now has the filename of the result on the target system. It copies the result from the target to itself and processes it. All good so far.


We could never make Windows work this way. The account we use for Apache is the standard "Local System" account. This account has no access to network resources. Hence it cannot simply copy the script to or from a target PC. This was always a pain because the Linux way of running the Discovery was so much better and cleaner. After some (more) research we realised we can use network resources via "net use" - we simply don't assign a drive letter. Yay! So Windows now can copy the audit script to the target, run it, wait for the console output and then copy the result file back and process it, just like Linux.

NOTE - If you are seeing issues copying the scripts when using the default "Local System" account, please change the Apache service to use another assount. This account does not need any special access (as credentials are supplied for devices in Open-AudIT itself), it just needs "network" access.


All that is a long explanation for "we don't need the default network address set". That's one less item a user needs to worry about.

We do still have the requirement to set the default network address for the functionality of the "Audit My PC" on the login page. We have plans to minimise this as well - if you can view the login page, we can use the request URL and work out what the default network address should be.

For now it's still required (as at 3.1.0), but look for it to be removed as a requirement in a near future release.

One step at a time, we're trying to make Open-AudIT as easy to use as possible.

Onwards and upwards.

Mark Unwin.