Apologies for putting this all in one post with a generic title, let me know if it would be better to split it all up into multiple posts for tracking or voting 
We have identified several enhancements to webhooks that we believe would be extremely useful to everyone, and would definitely save us a LOT of time and effort. These are particularly suited for Doppler webhooks that call Github Actions but probably apply to other situations just as well.
The same major pain points apply to everything below:
- Rotating auth keys is a huge pain with Doppler webhooks. Github PAT expired? You have to delete and re-create every single webhook you have setup using that PAT.
- Every webhook has a distinct custom payload (with Github, possibly others) due to required fields on the consumer’s side. You can’t easily see this payload after it is set, making the re-creation of webhooks extra painful.
- Ironically, Doppler doesn’t support reading from Doppler for the auth of a webhook, so you’re copy/pasting that token however many times. Not only inefficient and not scalable, but this means that in most orgs the roles that actually can do the rotation is very limited due to least-privilige.
API to create/update webhooks
This would effectively solve all of our issues, so if there’s one thing in this feature list that gets added to the roadmap I hope this is it.
An API endpoint to CRUD webhooks, just like most everything else in Doppler, would be extremely useful. Not only would it open the pathway to adding webhooks to the Terraform provider, but it could provide a way to validate a given configuration.
This would still require bespoke payloads and re-creation of webhooks when tokens expire, but it would make that an automatable process.
Ability to modify the default payload or merge it with the custom payload
In the case of Github Actions you must provide an event_type field in your payload. This means that you can’t use the default payload at all - it’ll never actually kick anything off on the Github side.
If we could modify the default payload to add that field, or have some merging of the custom payload it would allow us to unify our payloads into a single approach and just use the default payload’s config and project fields in our workflows. In fact, this would mean we’d only need a SINGLE webhook per project instead of the multiple we currently have to create.
Ability to pull auth information from Doppler
It would be very helpful in general - and massively reduce the overhead involved with token rotation - if we could pull the auth token from Doppler directly. Something like the current secret references using ${project.prd.WEBHOOK_TOKEN} would give us the ability to lock that project down and allow teams to create their own webhooks.
In our org, the access to the PAT involved is locked down to only a select few people due to a handful of security and compliance requriements. This means that only those select few people can create webhooks, and are effectively on the hook for anything that happens with them. With many teams and projects, this could cause a lot of friction.
Even better in this case would be the ability to lock down access to changing the auth token separately from webhook permissions (see the next request below), so that no bad actors could just drop in their own auth tokens and bypass intended guardrails.
Webhooks permissions options
Some permissions options around webhooks feel like a necessity. Currently it’s all or nothing, unless I’m holding it wrong.
On top of splitting out webhook permissions to their own item in the first place, some specific permissions/options that we would love to see that meld with the above requests:
- Restrict changing auth tokens from project/workspace default, if the ability to pull that from Doppler was added.
- Allowed URL prefixes, ex: only destinations starting with https://api.github.com/repos/my-org/ are allowed. This would prevent a lot of bad actor possibilities outright.
Some indication that webhooks were called at all
This all cropped up after a PAT expired and suddenly our Actions weren’t running, and it was not at all obvious whether Doppler was even calling them in the first place. Just a simple item in the logs saying “Webhook with $URL was called” would be plenty to satisfy this request. Being able to see the payload that was sent would be extra helpful, and would help solve for some of the issues called out at the top of the post.
As mentioned, the API endpoints to CRUD webhooks in Doppler would solve our painpoints well enough but I really hope some of these other options can be considered. Thanks!
