Web Service vs. API

Shawn Beasley07. May 2019 | Miscellaneous

OTRS, as a glue-ware, offers you the flexibility to maintain service-relevant information anywhere. Retrieval of the information, and providing service request-related data to third parties, is simple. A web service, known as the Generic Interface, has been the answer to this since its introduction in OTRS 3.1. The web service provides access via HTTP by means of SOAP or REST to the internal OTRS API. The OTRS API is written in Perl, and by using the web service operations, standardized communication is possible. It’s not necessary to understand how the Perl API works in order to use internal functions of OTRS: Instead, operations are provided which can be made available to external systems or used to request information from these systems.

Learn how our new REST API can make simple integrations faster than ever.

The major difference is that our API is now forward-facing, as opposed to having to access the Perl API via REST Operations. The middle man has been cut out. There are advantages and drawbacks. We will focus on the advantages, which include:

  • Speed of deployment
  • Zero configuration
  • Standardized documentation
  • High flexibility
  • Increased security

The external interface’s front-facing RESTful API is available out-of-the-box with OTRS 7. The Generic Interface needs no configuration, as was needed in the past, because the endpoints and network transport are already defined. Perl is still under the hood, but instead of using special Perl Operations (limited functionality) provided the by Generic Interface, each endpoint is pre-defined (eg., Facebook, Google, etc). The documentation for the endpoints is available online and updated as new versions are built. The API documentation conforms to today’s API documentation standards in terms of how it is designed, delivered and easy-to-consume with examples and response codes for quick reference. You now have more flexibility than ever for accessing information which was not previously available with Generic Interface operations like customer user profile (/api/customer/account/personal-preferences information) and form data requirements (/api/frontend/external/form/ticket).

A simple ticket create can now be performed with very little effort. Authentication is sent in the header (make sure you generate a token /api/customer/auth/login), or it can be alternatively stored in a cookie. A payload like this is enough to create a ticket.


Method POST

jSON Body

I look forward to hearing about your use cases.

Warm Wishes,


“Man invented language to satisfy his deep need to complain.”

Shawn Beasley at 17.06.2019, 21:10

You should look at. https://doc.otrs.com/doc/api/otrs/stable/REST/#panel_api_customer_ticket__ticketid__article

Rene at 17.06.2019, 15:22


Shawn Beasley at 14.06.2019, 12:53

You are talking about OTRS 7, correct?

Rene at 20.05.2019, 15:17

Thanks for your answer, but I meant something different. OTRS accepting a request for TicketUpdate (e.g. a dynamic field). Like your example, but not creating a new ticket, but updating an existing one. I cannot find this case in the REST API documentation.

Shawn Beasley at 20.05.2019, 08:43

Currently this API only accepts requests. If you need to send updates, then the OTRSTicketInvoker is the way to go. Please contact sales@otrs.com.

Rene at 16.05.2019, 11:47

Hi Shawn, ist ist also possible to send a TicketUpdate (e.g. update a dynamic field) request using this REST API? I could not find it in the REST API documentation.

Your email address will not be published. Required fields are marked *

This site uses cookies. By continuing to use the site, you agree to the use of cookies. More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.