Send Webhook Messages with content-type application/json

[Joe.Thorpe]

Hi Mike / Scott,

We're using JIWA's webhooks through a Microsoft Power Automate Custom Connector. Power Automate requires webhook messages to have a content-type of application/json (https://docs.microsoft.com/en-us/connec ... ok-trigger)

I modified this code in the REST API Plugin (v7.2.1.23 line 29348 in WebhookController.CallWebhook) to specify the content type:
subscription.URL.PostStringToUrl(message.Body,
contentType: "application/json",
requestFilter: webRequest =>


This works, but would it be possible for you to make this change in a future version of a the plugin? That way, i wouldn't need to patch the plugin each time there's an update.


Power Automate Custom Connectors have some other requirements, but i was able to workaround them with a seperate plugin. I'm happy to talk about that if you're interested in supporting PA Custom Connectors out of the box.

Cheers,
Joe

[Mike.Sheen]

Hi Joe,

We already support the adding of any desired header to a webhook POST without modifying the plugin.

You can add request headers via the PUT request on /Webhooks/Subscribers/{SubscriberID}/Subscriptions/{SubscriptionID}/RequestHeaders/

Mike

[Joe.Thorpe]

Hi Mike,

Thanks for the suggestion. I did try that, but you can't modify the Content-Type header this way.

The SY_WebhookMessageResponse record shows:
The 'Content-Type' header must be modified using the appropriate property or method.
Parameter name: name

This is a limitation (security feature?) of the underlying .NET library (https://stackoverflow.com/questions/450 ... rty-or-met)

[Mike.Sheen]

Hi Mike,

Thanks for the suggestion. I did try that, but you can't modify the Content-Type header this way.

The SY_WebhookMessageResponse record shows:
The 'Content-Type' header must be modified using the appropriate property or method.
Parameter name: name

This is a limitation (security feature?) of the underlying .NET library (https://stackoverflow.com/questions/450 ... rty-or-met)

Correct - we fixed this in DEV-8635 - I thought we had also applied a fix to the 7.2.1 branch - but it does not look like it.

In any case, it is fixed in the next version - so your fears of your temporary fix being un-done in the next release can be put to rest.

[Joe.Thorpe]

Oh awesome, thanks!