Skip to main content
Solved

Issue Handling Webhooks with Empty Body in FME Flow

  • November 24, 2025
  • 4 replies
  • 170 views

arild_f
Contributor
Forum|alt.badge.img+5

Hello FME Community,

I’ve encountered an issue in FME Flow and would appreciate your input.

We have an automation webhook that receives messages from another system and then triggers a workspace. The source system is a building management system used by our real estate department. It sends a message whenever a new building is added or an existing building is updated, and this works perfectly.

However, the problem occurs when a building is deleted. The delete message contains data only in the header and nothing in the body. As a result, FME Flow returns a 400 Bad Request error with the following output: {"message": "JSON Parse Error: Unable to read message body"}.

The error goes away if I add {} in the body in Postman and then send the message to Flow.

I’ve spoken with the administrator of the building management system about the possibility of including {} in the body, but unfortunately, that’s not an option.

 

Question:
Is there a way to configure FME Flow to accept a webhook with an empty body?

 

We are currently running FME Flow 2025.1.1.

Thank you for any suggestions!

Best answer by zoe.forbes

Thanks for the existing answers on this post! I wanted to add a potential solution.

If you have no control of the format of the webhook being received by Flow, one option is to use Data Virtualization. I can see two ways this could be implemented:

  • As middleware, like ​@virtualcitymatt said. Use a Tester to check if the incoming POST request has a body, and two HTTPCallers to either pass on the existing body or add a blank one. You could then pass the response of the HTTPCaller to the DV writer.
  • Alternatively, you could change the Automation’s trigger to a Manual Trigger and call the API endpoint /automations/{id}/trigger from within the Data Virtualization workspace. This has the advantage of making sure the automation can only be called publicly from one place, but would take more work to implement.

Note that no additional engines would be required for these solutions, as these API calls are asynchronous.

This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

4 replies

geomancer
Evangelist
Forum|alt.badge.img+61
  • Evangelist
  • November 24, 2025

Can you add the {} in the body yourself when it is needed, before processing the JSON data?

Like this: Process the input as text (setting parameter Read Whole File at Once to 'Yes’), add {} in the body when needed (maybe using StringReplacer in mode 'Replace Regular Expression’), and process the result as JSON like you already do.


virtualcitymatt
Celebrity
Forum|alt.badge.img+47

The problem is happening before the data even enter the FME ecosystem so there's not much he can do on the FME side. 

Perhaps some middleware to add a {} in case its empty? Sees a little unnecessary. 

How's the request being sent? If it's with curl it should be easy enough to just set an empty body to {}.

It does seem like a bit of a limitation that the POST must have a body. 


virtualcitymatt
Celebrity
Forum|alt.badge.img+47

Does the Webhook Trigger node output a failed feature in the case of this 400 response? That would be nice. The doc suggest that it should, but in my testing in the past I didn't see that happen


zoe.forbes
Safer
Forum|alt.badge.img+5
  • Safer
  • Best Answer
  • December 5, 2025

Thanks for the existing answers on this post! I wanted to add a potential solution.

If you have no control of the format of the webhook being received by Flow, one option is to use Data Virtualization. I can see two ways this could be implemented:

  • As middleware, like ​@virtualcitymatt said. Use a Tester to check if the incoming POST request has a body, and two HTTPCallers to either pass on the existing body or add a blank one. You could then pass the response of the HTTPCaller to the DV writer.
  • Alternatively, you could change the Automation’s trigger to a Manual Trigger and call the API endpoint /automations/{id}/trigger from within the Data Virtualization workspace. This has the advantage of making sure the automation can only be called publicly from one place, but would take more work to implement.

Note that no additional engines would be required for these solutions, as these API calls are asynchronous.