Get more done with less effort by using queue preferences in REST requests.

Billing customers can be a daunting task, especially when you’re dealing with individual service requests. By adding billing codes to our requests using queue preferences, and leveraging generic interface, you can automatically send information to another system for billing.

Task

Record billing positions, for monthly billing to an external table.

Prerequisite

As described in Revolutionize your experience with queue preferences, we showed you how to add a queue preference. In this week’s tip, we want to show you how to access this queue preference and use it in a web service request. The generic interface can be used to access any APIs supporting REST and SOAP.

Example

In this example, we would like to access the Airtable API, to record the customer, the time spent within the ticket, and the billing code for the request. The customer and time spent will be used from the accounted time feature and customer data within the ticket. The billing code will be read from the queue preference, by the generic interface module.

We will write a new row of data for each ticket closed, which contains a billing code. This will not require the user to select this data manually; all that will be required is for the user to account for the time within the ticket. Upon closing, we will automatically generate the needed reports.

Setup

Airtable

(See Airtable documentation for more information)

Create an Account, if needed.
Create a Workspace
Create an API Key
Access the API Documentation

Znuny

The following screens show the configuration, based on a fictive account.

Create a web service
Select and configure the transport

**NOTE** Don't forget to come back after you create the invoker, to set Endpoint, Controller Mapping, and Authorization Header
Add and configure an invoker
Create an XSLT mapping

Once this is set up, (in my case you need to add a new state to the system), then you can start testing. Errors in mapping, transport and responses can be tracked in the web service debugger.

In concluding, using the generic interface in a quick and easy solution for updating external systems and interface with external processes. This will not only streamline your business, but increase profits by reducing errors, transmission times and human error.

Blogpost

Posts within the same category

Sep 19, 2025

When Mail Intake Breaks, CLI Saves the Day

Recovering from Procmail misconfigurations and spool file buildup is simple with Znuny and formail.

In a perfect world, incoming emails flow seamlessly into your Znuny ticketing system and are processed without delay. But in reality, even a small misconfiguration — especially when direct delivery is done via procmail — can quietly derail your mail intake.

Instead of creating tickets, Znuny’s expected mail accumulates messages in the local spool file (e.g., /var/spool/mail/znuny). No alerts. No tickets. Just a growing backlog of unprocessed mail.

Sep 4, 2025

Turning Process Maps into Power Moves with Znuny

Managing change requests can feel like herding cats — multiple stakeholders, shifting priorities, and the constant risk of something slipping through the cracks. That’s where a well‑designed workflow becomes your secret weapon. In this guide, we’ll take a clean, visual BPMN process map and bring it to life inside Znuny, the open‑source ticketing powerhouse. You’ll see exactly how to turn decision points into automated transitions, keep every step accountable, and make sure no request dies in someone’s inbox. By the end, you’ll have a repeatable, auditable process that your team can follow without missing a beat.

View all