Send E-Mails via Web Service

Robert Ullrich03. Sep 2018 | ConsultingCyber SecurityUse cases

Disclaimer:

The practical examples presented in our technical blog (blog.otrs.com) 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.

One of the key features of “STORM powered by OTRS” is automizing daily manual tasks. Some months ago I was with a CERT team and they want to create & update tickets in STORM and afterwards send emails to the recipients. To solve this requirement we used the STORM exclusive functionality “ArticleSend”.

The best thing is, that it’s also working with your web service operations which already exists in your STORM system.

If you have a STORM system, take a REST Client (e.g.: Boomerang) and send one the following JSON strings to your TicketCreate / TicketUpdate endpoint:

Example for TicketCreate with ArticleSend:

{
"Ticket": {
"Title": "Some ticket title",
"Queue": "<a valid queue name>",
"Lock": "unlock",
"Type": "<a valid ticket type>",
"State": "<a valid state e.g.: Incident>",
"Priority": "<a valid ticket priority e.g.: 3 normal>",
"Owner": "<a valid STORM user e.g.: root@localhost>",
"CustomerUser": "your@recipient.com"
},
"Article": {
"To": "your@recipient.com",
"ContentType": "text/html; charset=UTF8",
"CommunicationChannel": "Email",
"SenderType": "agent",
"Subject": "ArticleSend via REST",
"Body": "Some text send via REST",
"IsVisibleForCustomer": "1"
},
"UserLogin": "<Your_web_service_user>",
"Password": "<Password>"
}

Example for TicketUpdate with ArticleSend:

{
"Article": {
"To": "your@recipient.com",
"ContentType": "text/html; charset=UTF8",
"CommunicationChannel": "Email",
"SenderType": "agent",
"Subject": "ArticleSend via REST",
"Body": "Some text send via REST",
"IsVisibleForCustomer": "1"
},
"UserLogin": "<Your_web_service_user>",
"Password": "<Password>",
"TicketID": "<TicketID>",
}

I would really like to see your usecases, so please leave a comment.

#5
Sergio Castañeda at 23.11.2023, 22:18

This comment is awaiting moderation.

#4
Jens Bothe at 21.02.2023, 19:29

Use the ticket notification or much better upgrade to a supported version of OTRS as OTRS 6 is outdated and filled with known vulnerabilities since years

#3
Zhamila at 21.02.2023, 10:55

Jens, You're right, i have overlooked it. So anyway the construction of JSON looks similar for Generic Interface OTRS 6. Can i somehow overcome the problem when "Queue" value is thrown out to "Receiver" field in the webservice? Want my customer receive emails about new tickets.

#2
Jens Bothe at 20.02.2023, 18:20

As you might have not read the first sentence, this feature was exclusive for STORM powered by OTRS. It was integrated in newer versions of OTRS. Actual OTRS 8 is the stable version. So you might need to upgrade first.

#1
Zhamila at 20.02.2023, 17:06

Hello! I tried to send similar JSON to Ticket Create endpoint. But there is a major point. Regardless "Customer User" an "To" are defined the article's receiver is displayed as the value of my "Queue". Consequently email notification isn't sent to recipient address. I've done so many probes with different parameters, but the result is same. Seems there is a default setting that doesn't take into account the parameter "To" in article definition. Do you know why it takes place? Thank you.

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