We Have the Connector: API Extensions for OTOBO and Znuny

Stock OTOBO and Znuny already expose ticket create, get, search, and update through the Generic Interface. That is enough to move tickets — it is not enough for an AI runtime or Studio that must sync queues, states, priorities, services, types, Dynamic Fields, and FAQ before it can classify or route anything.

That is why we ship the Open Ticket AI Connector: a package that installs one REST webservice named OpenTicketAI and registers extra Generic Interface operations on top of the built-in ticket API.

The connector is how Open Ticket AI talks to OTOBO 11 and Znuny on-premise. No SaaS hop, no second ticket store — the ticket system stays the system of record.

What the connector installs

On install the package does two things:

1. Creates a restricted API agent used only by Open Ticket AI (OTOBO default login otai-webservice; Znuny default open_ticket_ai).
2. Imports a single Generic Interface REST webservice OpenTicketAI, locked to that user so other agents cannot call it.

It also ensures an ai-agent group exists. FAQ categories you want the AI to search must be granted to that group (in addition to users for human agents).

Ticket operations plus catalogue extensions

The webservice keeps the familiar ticket routes and adds catalogue operations we implemented as TicketAICatalog::* modules:

Base URL:

<host>/<otobo|znuny>/nph-genericinterface.pl/Webservice/OpenTicketAI/<route>

Authentication is HTTP Basic Auth with the API agent credentials.

How an extension looks in code

Each catalogue operation is a Generic Interface module. After auth it reads native OTOBO/Znuny objects and returns a stable JSON list — here, queues:

package Kernel::GenericInterface::Operation::TicketAICatalog::QueueList;

use parent qw(Kernel::GenericInterface::Operation::TicketAICatalog::Base);

sub Run {
    my ( $Self, %Param ) = @_;

    my ( $UserID, $Error ) = $Self->_AuthOrError(%Param);
    return $Error if $Error;

    my $QueueObject = $Kernel::OM->Get('Kernel::System::Queue');
    my %Queues      = $QueueObject->QueueList( Valid => 0 );

    my @Items;
    for my $QueueID ( sort { $a <=> $b } keys %Queues ) {
        my %Queue = $QueueObject->QueueGet( ID => $QueueID );
        next if !%Queue;
        push @Items, {
            ID      => $QueueID + 0,
            Name    => $Queue{Name} // $Queues{$QueueID},
            Comment => $Queue{Comment} // '',
            Valid   => ( ( $Queue{ValidID} // 1 ) == 1 ) ? 1 : 0,
        };
    }

    return {
        Success => 1,
        Data    => { Item => \@Items },
    };
}

The same pattern covers states, priorities, services, types, and Dynamic Fields. DynamicFieldCreate can create or update a Ticket dropdown field and enable it on the usual agent screens. FAQSearch queries customer-visible FAQ articles and fails softly if the FAQ package is not installed.

Operations are registered in SysConfig as Generic Interface modules, for example TicketAICatalog::QueueList and TicketAICatalog::FAQSearch.

Why this matters for AI on the helpdesk

Without catalogue endpoints, an external engine can only guess queue names from ticket text. With the connector, Studio and the runtime sync the live catalogue, map predictions to real IDs, and write back through TicketUpdate — including Dynamic Fields.

Related packages on the same stack:

• OTAIStudio — SSO from the agent UI into Open Ticket AI Studio (requires this connector).
• Optional agent screens for attributes and human review of AI suggestions.

OTOBO and Znuny

The Generic Interface operation names stay the same on both systems. OTOBO reads the API password from the process environment (OTAI_TICKETSYSTEM_PASSWORD); Znuny uses SysConfig (OpenTicketAIConnector::AgentPassword) before install.

Next step

If you run OTOBO or Znuny and want on-prem ticket AI with a proper API — not a brittle scrape of the agent UI — this connector is the integration layer we use in production.

Read more about the product on openticketai.com or get in touch.