Hey all,
Across all my applications, any “Call API” action that contains body content is throwing a “Failed to trigger webhook” error.
Removing the payload enables the webhook to be called, so there must be a payload parsing issue of some such.
Hey all,
Across all my applications, any “Call API” action that contains body content is throwing a “Failed to trigger webhook” error.
Removing the payload enables the webhook to be called, so there must be a payload parsing issue of some such.
Hey @visionist
Thanks for flagging this! ![]()
This can happen if the receiving endpoint or service isn’t expecting the exact payload format that Softr sends. When there’s body content, Softr sends the data as JSON by default — so if the endpoint isn’t configured to accept application/json, it may reject the request and return a “Failed to trigger webhook” error.
Can you please make sure your API endpoint expects JSON and has the Content-Type: application/json header.
If removing the body makes it work, that confirms the webhook URL itself is fine — it’s just about how the payload is being parsed or accepted.
Could you share what service you’re sending the request to (e.g., Make, Zapier, a custom endpoint)? That’ll help us guide you better.
Hey Andranik,
Thanks for the follow-up. Good news is that the issue has been resolved, whatever it may have been — my Call API actions across all apps are now triggering with payload data intact.
I use make.com scenarios. No matter the scenario, however, the actual endpoint was not arriving from Softr if it contained a dynamic payload (scenarios never saw the API call). Interestingly, it did work if I built static payloads manually (using manually-entered “Custom Values” instead of selecting data fields from the Softr blocks).
So it seems there was a disconnect between the blocks/data sources and the API Call, as any lava value included in the payload would cause the error, and the API call would fail to actually trigger (at least for all my apps, which are all sourced from Airtable).
Glad its working as of this morning, however!
Thanks much.
Awesome news! thanks for keeping us posted!
Best regards,
This exact issue is occurring for me today. Was there any resolution to this other than waiting for the issue to magically dissappear?
@Steve afaik the issue was that make was returning non JSON response as a content type… pls check or share more details what has been failing
@Steve It has happened to me a few more times as well. I was able to correct it by rebuilding each API action key. Try 1) Deleting all your key/value pairs, save, then 2) add one key pair in, save, and test the call. Repeat until you’ve added all your pairs back in. I found that there was one pair in particular that it didn’t like (Usually a recordId of some kind).
I noticed that the payload structure being send across the API action had been updated recently, as it now seems to be handling native arrays better. If that’s true, maybe its rebuilding the action within the updated version is putting it back on track. ![]()
@Andranik Please be advised that the API action is still a little glitchy – failing to trigger the webhook on actions that have historically had no issue.
Super helpful. Thanks!