Automatically detect the gender of your customer user

Robert Ullrich21. Jun 2018 | Best PracticesCase studyConsultingUse cases


The practical examples presented in our technical blog ( and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept. 

We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.

I think everyone of you have asked yourself the question (especially the german OTRS administrators), if it’s possible to automatically detect the gender of your customer users. This might be useful if the gender is missing in your customer user backend or someone is writing you an email, who is not stored in your backend. So keep on reading, because I want to show you how to build such a “GenderAPIConnector”. In part 1 of this small blog article series I want to show you how to set up the web service to automatically check the gender of the sender.

Important note:

Keep in mind, the OTRS Blog should only show you the technical possibilities you have with OTRS, the OTRS API and other tools/services. Based on the new General Data Protection Regulation, which is enforced since may 2018, you should think about if you really need the gender of a person for your service management.

Last week I discovered another useful third-party provider, which makes it possible! The name of this provider is “Gender API“.

We have some pre-requirements before we can start:

  1. Go to and register a new account
  2. After registration you’ll receive 500 credits, but you can buy more
  3. Note your API key. You can also find it in your Overview (at the end of the site)

GenderAPIConnector Overview

OTRS Requirements for this HowTo

OTRS Framework

  • at least OTRS 6.0.x

OTRS Packages

You need the following OTRS Feature Add-On:

  • OTRSTicketInvoker
(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)

Third Party Software

You need this third-party software:

  • XML::Simple
  • XML::LibXML
  • XML::LibXSLT

Dynamic fields in OTRS

  • Firstname – of type text – to store the firstname of the customer user
  • Gender – of type text – to store the gender (response) from GenderAPI

Configuring the GenderAPIConnector in OTRS

As always we need a new web service in OTRS. Call it “GenderAPIConnector”:

GenderAPIConnector General Config

Let’s continue with our invoker. The name for my invoker is “detectgender”. Because I want to reduce my payload, I’m only using the dynamic field “Firstname” in my outgoing request data. I also use “XSLT” for my outgoing an incoming mapping:

GenderAPIConnector Invoker Config

My outgoing XSLT mapping is the following:

GenderAPIConnector Invoker XSLT outgoing

Because the invoker will receive an answer immediately, we need a XSLT mapping for the incoming response data. You can use the following example:

GenderAPIConnector Invoker XSLT incoming

The response should be stored in the dynamic field “Gender”. We also have to tell the invoker, when he should be triggered towards GenderAPI. Because of this I’m using the event “TicketDynamicFieldUpdate_Firstname”:

GenderAPIConnector General Config 1

The last point for my first GenderAPI example is the configuration of the transport. Pay attention to the controller mapping, because GenderAPI is expecting everything as query params (also the API key). The valid request method for this controller is GET. If you do the same than I did, it should work as expected.

GenderAPIConnector Transport ConfigThat’s all for this invoker. Let’s start our tests.

Testing the GenderAPIConnector

Depending on your configured event trigger for the invoker, please create a new ticket or (as I’m doing) lock the ticket to yourself. You should now see something similiar in the web service debug log:

GenderAPIConnector Debug log

In the ticket history of the specific ticket we now see the value for the gender:

GenderAPIConnector ticket history


What can we now do with this information? I’ll show you next time.

More information about the Gender API

Please go to the following website, if you need more information:

David at 05.10.2023, 19:51

This comment is awaiting moderation.

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