Triggers posting to third party URL: Not sending headers

[Lindsay Klatzkin]

My goal is to send JSON formatted data to Mulesoft.

• Created "HTTP Post" trigger
• Created a template which has valid JSON
• Set the Trigger Type properties to JSON
• Confirmed the preview is generating valid JSON
• Trigger the trigger -- mulesoft reads the request headers as "application/x-www-form-urlencoded"

I would have expected that the headers would be sending application/json in the headers with this option selected.  I have tried changing the template's "template type" from "generic" to "http post" and this has not changed.

What do I have to do to get the trigger to send the correct content-type headers?

[Lee Savidge]

I don't know mulesoft, but I use the triggers regularly to post out to an external application and the easiest way is to use name-value pairs. It posts them as a form post,  the MIME type is application/x-www-form-urlencoded, and you can pick that up in Mulesoft https://help.mulesoft.com/s/question/0D52T00004mXXkzSAG/xwwwformurlencoded-in-http-request-connector-as-post

Your mileage may vary. I write my own APIs in C# using MVC and post out to them using triggers or smart events, but either way, the name-value pairs is the easiest. You write out which fields you want in the arguments text box as a list like this:

sessionid={!USERPROFILE.SESSIONID!}
endpoint={!API_ENDPOINT!}
useremail={!USERPROFILE.EMAIL!}
authkey={!COMPANY.AUTH_KEY!}
profile=randomstring
entityid={!SODOCUMENT.MEGAENTITYID!}
type=PriceList
implementationorlive=Live
sessionorwslogin=webservices

The above is an example, but in EVERY smart event/trigger I do, I pass at least the first 3, if anything, just for logging purposes. The rest in this example are either custom fields, standard fields or strings I need to pass. In my C# code, I pick these out from the Request.Form in a foreach loop. After that, you do what you want.

foreach (var formVar in Request.Form)

[Lindsay Klatzkin]

Thanks Lee.  I'm just wondering why Intacct would offer JSON as an option without setting the content-type header to application/json.

[Lee Savidge]

I would imagine it is setting the content type appropriately. If I was curious, I would set up a small web service and call if from the trigger and query the content type just to see, but I would be surprised if it doesn't. That being said, I've never bothered as it is easier to write a key/value pair list than it is to write JSON by hand which is why I always use the name/value pairs.

[Lindsay Klatzkin]

I discovered that this was a bug in the "preview/debug trigger" functionality.  When the trigger is actually triggered by an event, it does send "application/JSON" headers.  But when debugging the trigger, it did sent the headers as "application/x-www-form-urlencoded".