Feature Request: Allow tenant-specific alert URLs in multi-tenant environments
I maintainer di solito rispondono entro 1 giorno
@alexluong ci sta già lavorando.
Dal 3/9/2025.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Is your feature request related to a problem? Please describe.
Yes. Although Hookdeck Outpost supports multi-tenancy — which is a great fit for our multi-tenant SaaS architecture — the "Alerts" mechanism currently uses a single global configuration for the alert delivery URL (set via environment variable). This means that all alerts for all tenants are sent to the same endpoint, making it difficult to isolate, route, or process alert events per tenant.
Describe the solution you'd like
We would like the alert delivery URL to be configurable per tenant. Ideally, this configuration would be part of the tenant creation/update API so that each tenant can have its own dedicated alert endpoint.
Alternatively, support for URL placeholders in the global alert URL (e.g., using {{tenantid}}) would be helpful:
https://{{tenantid}}.mydomain.com/webhook/alerts
This would allow tenant-specific routing even with a single environment variable, by dynamically resolving the URL based on the tenant ID associated with the failed webhook.
Describe alternatives you've considered
Currently, we're using a shared alert receiver that parses the destination ID and attempts to route internally based on that, but it's fragile and leads to tighter coupling. Having a clean per-tenant alert URL would simplify our architecture and improve observability.
Additional context
In multi-tenant SaaS scenarios where each tenant has its own infrastructure or integration pipeline, isolating alerts is critical. Allowing tenant-level alert URLs makes the platform much more flexible and production-ready for complex use cases.
- Lingua principale
- Go
- Stelle
- 1.1k
- Fork
- 70
- Merge medio
- 1g 3h
- PR unite (30g)
- 50
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di hookdeck/outpost
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
hookdeck/outpost#1117 · 1 commento · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di hookdeck/outpost
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
agent-review-finding bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
jordansmall/spindrift#5281 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
github/github-mcp-server#3489 ·
I maintainer di solito rispondono entro 4 giorni
-
L: java:gradle L: java:maven L: ruby:bundler T: bug 🐞
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
dependabot/dependabot-core#16547 ·
I maintainer di solito rispondono entro 1 giorno
-
Docs/examples still create key ranges in ascending order, which fails in 3.1.0 (follow-up to #1754)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
pg-sharding/spqr#3083 ·
I maintainer di solito rispondono entro 1 giorno