Skip to content
OTOBO Community Guide

OTOBO Interface: Web Services & Integrations

In this guide: Conceptual overview of OTOBO web services — when to use operations vs. invokers and how mapping works.

Related: REST API reference · Ticket services · Process management · OTOBO automation & integration by Softoft

OTOBO web services Generic Interface

Introduction to integrating external interfaces

Section titled “Introduction to integrating external interfaces”

In a globally connected world, ticket systems must be able to react automatically to requests from other systems and be able to send requests or data to external services. OTOBO, the powerful open-source ticket system, meets this challenge with its Generic Interface. It allows administrators to create web services for a variety of tasks without deep programming knowledge. OTOBO supports communication via REST and SOAP protocols, enabling seamless integration with:

  • CRM systems
  • Project management systems
  • Document management systems
  • and many other applications

A web service acts as a link between OTOBO and external systems. In this process, Operations and Invokers define the direction of communication, while Mapping and Transport determine how data is transmitted and interpreted. With OTOBO, you can configure web services to perform actions internally, initiate requests on remote systems, manage data conversions between systems, and define the communication protocol.

Access to the Web Services can be found in the Web Services module within the Processes & Automation group. A fresh installation of OTOBO does not contain any pre-configured web services by default. The following documentation illustrates how web services can be created, edited, deleted, cloned, exported, and imported, as well as the use of the debugger tool. For this, please refer to the steps detailed in the official OTOBO administration documentation.

Implementation of the interfaces

Section titled “Implementation of the interfaces”

The implementation of web services in OTOBO enables a flexible and dynamic integration of your business processes with numerous external tools and systems. By generating and using these Services, efficiency is increased by reducing manual intervention and shortening response times to client requests. Furthermore, the versatility of the generic interface ensures that OTOBO is almost infinitely extensible and thus fits perfectly into existing IT landscapes.

Security and configuration

Section titled “Security and configuration”

Regarding the configuration and security of web services, it is important to note that all saved passwords are exported in plain text during an export. The storage and handling of passwords should therefore be treated with special care.

For detailed information on system-internal configuration, such as the configuration options for cache and frontend modules, we recommend consulting the document otobo-system-configuration.txt. This source provides a comprehensive overview of all configuration options.

Documentation of the connections

Section titled “Documentation of the connections”

In an increasingly digitized operating environment, web services offer the possibility to link OTOBO with other systems and services. Ensuring efficient and secure communication therefore means configuring web service settings precisely in advance. The basics of the settings for web services in OTOBO are explained in more detail below to provide you with a more comprehensive guide.

General interface settings

Section titled “General interface settings”

  • Name*

    • The name uniquely identifies the web service within OTOBO. It is important to choose a clear and descriptive name that reflects the function or the partner being interacted with.

  • Description

    • An extended comment that details the purpose and functionality of the web service. This improves clarity and maintainability.

  • Remote system

    • Allows you to specify the name of the external system with which OTOBO interacts.

  • Debug threshold

    • Choose how detailed the logging of the communication should be. The settings range from Debug (most detailed logging) to Error (only error messages).

  • Validity

    • Determines whether the web service is activated (valid) or deactivated (invalid, temporarily invalid). Only valid web services are executed by OTOBO.

Network transport - SOAP or REST

Section titled “Network transport - SOAP or REST”

Different protocols are available for implementing integration with other systems. Here, the choice of network transport is fundamental:

  • Network transport

    • Choose between HTTP::REST and HTTP::SOAP. These protocols define how data transmission occurs between the OTOBO ticket system and the connected system.

  • Add operation

    • Allows you to define specific actions, so-called operations, for the web service. You can choose from a variety of predefined operations, such as Ticket::TicketCreate for creating tickets.

Creating a ticket via REST

Section titled “Creating a ticket via REST”

A practical example illustrates the value of web services in OTOBO. The Ticket::TicketCreate operation can be set up via the HTTP::REST protocol. The defined routes allow external systems to create tickets in OTOBO using HTTP-POST requests. This realizes new dimensions of automation and integration, which can significantly increase process efficiency and customer satisfaction.

Web services and optional AI classification

Section titled “Web services and optional AI classification”

AI-based ticket classification add-ons (such as OpenTicketAI) typically use REST API access configured through web services. See the add-on documentation for required operations and mappings.

Security note

Section titled “Security note”

Please note that passwords can be exported in plain text when exporting web service settings. It is therefore essential to handle sensitive information in a protected manner and to observe security regulations.

The effective use of web services in OTOBO allows companies to make their workflows smarter and more agile. Through the precise configuration of web service settings, a solid foundation is created that allows OTOBO to be seamlessly integrated into a company’s digital ecosystem. Web service settings and operations in OTOBO

The integration of external systems with OTOBO via web services is an essential component to ensure efficient ticket management. This integration is enabled by the definition of various operations that can perform specific actions within the ticket lifecycle. A significant part of this integration is understanding the necessary attributes for each operation as well as using the XSLT standard for data transmission.

Required attributes for interface operations

Section titled “Required attributes for interface operations”

Specific attributes are required for the basic ticket operations in OTOBO. Here are links to the official resources that describe in detail the attributes required for creating, retrieving, updating, searching, and retrieving the history of tickets:

This documentation allows developers to perform adjustments precisely and ensure that all requests contain the necessary information to be processed successfully.

Using the XSLT standard for data transmission

Section titled “Using the XSLT standard for data transmission”

XSLT transformation is a powerful technique for converting incoming data from web service requests into a form that OTOBO can process. By, for example, creating a dynamic field “RemoteTicketID” for tickets, you can efficiently store and further process incoming data:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
        <Ticket>
            <DynamicField>
                <Name>RemoteTicketID</Name>
                <Value>
                    <xsl:value-of select="incidentID"/>
                </Value>
            </DynamicField>
        </Ticket>
    </xsl:template>
</xsl:stylesheet>

This example shows how you can transform the value of the incoming incidentID attribute into a ticket dynamic field named RemoteTicketID.

Web service settings: Requester

Section titled “Web service settings: Requester”

For the implementation of web service procedures as a requester, OTOBO offers the choice between the HTTP::REST and HTTP::SOAP protocols. Here, the choice of network transport is elementary to ensure a proper connection with the external system. After selecting the transport, the configuration must be saved and adjusted according to specific requirements.

Setting up an error handling module is also an important step to guarantee robust communication. OTOBO allows specific modules to be implemented and configured for this purpose.

Conclusion and further steps

Section titled “Conclusion and further steps”

By providing a versatile, configurable API for web services, OTOBO opens up a world of possibilities for the integration and automation of ticket management processes. By providing precise specifications and using standards like XSLT for data manipulation, OTOBO offers its users a flexible basis for expanding their ticketing systems in line with their specific business requirements.

Whether as a provider or requester, the precise handling of web service settings ensures seamless and efficient communication with external systems and services.

Custom OTOBO workflows & integrations

We build dependable web services, process management automations, and third-party integrations tailored to your IT landscape.

Discuss automation

Frequently asked questions

What is the OTOBO Generic Interface and what is its purpose?

The OTOBO Generic Interface serves as a powerful framework designed to enable seamless data exchange between OTOBO and various external systems. It allows administrators to configure web services using predefined building blocks, eliminating the need for extensive programming knowledge. Its primary purpose is to facilitate automated communication with other applications, such as CRM systems, project management tools, and document management systems. By supporting both REST and SOAP protocols, the Generic Interface ensures OTOBO can react to inbound requests from external services and send requests or data outbound as part of workflows, significantly enhancing process efficiency and integration capabilities within a globally connected IT landscape.

How do `Operations` and `Invokers` differ in OTOBO web services?

In OTOBO's web services, Operations and Invokers define the direction and nature of communication with external systems. Operations are configured to handle inbound requests to OTOBO. This means when an external system sends a request to OTOBO, an Operation processes that request, often resulting in an action within OTOBO, such as creating a ticket or updating customer information. Conversely, Invokers enable OTOBO to initiate outbound requests to external systems. They allow OTOBO to call external services as part of a workflow or automated process, for example, to update a record in a CRM system after a ticket status changes in OTOBO. Essentially, Operations make OTOBO a receiver, while Invokers make OTOBO an initiator in the communication flow.

How does data mapping work in OTOBO web services for external system integration?

Data mapping is a crucial component of OTOBO web services, enabling the transformation of data structures between OTOBO and connected external systems. It ensures that information exchanged between disparate systems is correctly interpreted and formatted, regardless of their native data models. This process involves both request mapping and response mapping. Request mapping translates incoming data from an external system into a format OTOBO can understand and process, for example, converting an external system's customer_id field to OTOBO's CustomerID. Response mapping, on the other hand, transforms OTOBO's internal data into the format expected by the external system for outbound communication. This bidirectional mapping capability is essential for seamless integration, allowing OTOBO to interact effectively with a wide array of CRM, ERP, and other business applications.

What are the key configuration settings for OTOBO web services?

Configuring OTOBO web services involves several key settings to ensure proper functionality and integration. These include:

  • Name: A unique, descriptive identifier for the web service.
  • Description: An extended comment detailing the web service's purpose and functionality for clarity and maintenance.
  • Remote system: Specifies the name of the external system OTOBO will interact with.
  • Debug threshold: Controls the level of logging detail, from Debug (most detailed) to Error (only error messages).
  • Validity: Determines if the web service is valid (active) or invalid (deactivated). Only valid web services are executed.
  • Network transport: Defines the communication protocol, choosing between HTTP::REST and HTTP::SOAP, which dictates how data is transmitted.
  • Add operation: Allows the definition of specific actions, such as Ticket::TicketCreate, that the web service can perform.

These settings collectively establish the foundation for how OTOBO communicates with and integrates into external IT landscapes.

What security considerations should I be aware of when configuring OTOBO web services?

When configuring OTOBO web services, security is a critical concern, particularly regarding sensitive information. It is crucial to be aware that all saved passwords associated with web services are exported in plain text during an export operation. This means that if web service settings are exported, any credentials stored within them become immediately visible and vulnerable. Therefore, the storage and handling of these passwords must be treated with exceptional care and adhere to strict security regulations. Administrators should employ robust password management practices and consider alternative authentication methods where possible. For comprehensive details on system-internal security configurations, including cache and frontend modules, it is highly recommended to consult the otobo-system-configuration.txt document, which provides an exhaustive overview of all relevant options.

How can OTOBO web services be used to automate ticket creation and integrate with AI classification?

OTOBO web services play a pivotal role in automating ticket creation and integrating with advanced functionalities like AI classification. A prime example is setting up the Ticket::TicketCreate operation via the HTTP::REST protocol. This allows external systems to send HTTP-POST requests to OTOBO, automatically generating new tickets based on predefined routes and data mapping. This significantly boosts process efficiency and customer satisfaction by reducing manual data entry. Furthermore, AI-based ticket classification add-ons, such as OpenTicketAI, typically leverage REST API access configured through OTOBO's web services. These add-ons utilize specific operations and mappings within the web service framework to classify incoming tickets automatically, streamlining workflows and ensuring tickets are routed to the correct departments or agents without human intervention.