svix-webhooks
svix-webhooks copied to clipboard
Add new options for prefix of whitelabel headers (whitelabel_headers_prefix)
Feature Request
Need to have whitelabel_headers_prefix, just like whitelabel_headers option in config. Example whitelabel_headers=true whitelabel_headers_prefix="CustomName-" default will be "Webhook-" Then configured white label headers will be CustomName-id, CustomName-timestamp, CustomName-signature default headers for whitelabel headers will be webhook-id, webhook-timestamp, webhook-signature
Motivation
Would be useful for clients to use their own specific header names
We only support the Webhook-
prefix for on purpose, and from our experience people don't really care about having a different prefix. I'd be happy to be swayed otherwise, but let me explain why we think that.
First of all, let me start by saying that the value of having Company-
over Webhook-
is limited anyway. As in, it doesn't provide any additional white labeling, so what you "give up" on here is very little, and the benefits for keeping it are large.
Some of the benefits:
- All of the Svix libs support
Webhook-
, so you get libraries for signature verifications for many languages for free. Maybe useful for you until you have libraries yourself, and when you do, you can just add wrappers around the Svix libs. - ngrok just added native support for Svix style
Webhook-
signatures, so ngrok customers will have built-in support for your webhooks too. - Our automatic Zapier integration builder supports
Webhook-
, but notCompany-
. - We are continuing to add things like the above, so as the ecosystem gets richer you'll continue benefiting from it.
This is why we haven't added it so far, and have no plans of doing it any time soon. Does that make sense?
Thanks for the reply. This is important for me. I want to make a pull request for this feature.
Can you please give me permission to create a branch and push my changes for this requested feature?
Can you please give me permission to create a branch and push my changes for this requested feature?
You don't need permission to create a pull request, you can just create fork the repo, create a branch there, and open a PR from that.
Thanks for the reply. This is important for me. I want to make a pull request for this feature.
Happy to discuss it over slack for a more rapid discussion. Though we definitely need to think about it further, as this is something we purposefully don't want to have because of the above. It adds little benefit (if at all) and it makes other things worse.