Form block call to Webhook does not have an HTTP Header option

Hello Softr.

Dynamic blocks’ action items’ Call API action has an option to supply an HTTP Header, which allows to utilize 3rd party webhooks’ ability to accept api keys in the header of the call for added security.

The Form block doesn’t have that for “Send to Webhook” option. I think it should for the same reasons.

I hope this can be added soon.

Thanks!

2 Likes

This functionality is desperately needed and without it, the webhook/make options are pointless because using them would create a critical vulnerability

1 Like

Hi folks,
Thanks a lot for bringing this up — that’s a great and very relevant suggestion.

The good news is that our team is already working on this!
We’ll soon introduce an app-level setting where you can define a token and then select to pass it (just like other user variables) when sending data through webhooks.

There’s no fixed ETA yet, but it’s planned to arrive within the next few weeks.

We’ll make sure to share an update here as soon as the feature goes live.

Thanks again for the valuable feedback — this kind of input really helps us improve Softr! :raising_hands:

Best regards,

2 Likes

Hi @Andranik, how’s things?

Checking in here as I too am keen to see this update - is there any news on progress?

Thanks.

I think now with workflows as a form destination more can be achieved

Yes, but then I am limited to the # of Softr workflow actions in my plan. For those of us who rely on more sophisticated 3rd party backend workflow systems (n8n, Make, etc…), we would only be paying to that service provider for workflow actions.

Why not just simply add HTTP header into your Form’s API callout action? You have HTTP header in API callouts in regular block actions. What’s different about Forms?

Thanks

We might but workflows also give you more options when it comes to UI interactions unlike third party versions… we will improve the form version too but given there is an alternative makes hard to make it a prio