chore(charts): sync SONIOX_API_KEY into backend secrets - #12298
Open
mdmohsin7 wants to merge 2 commits into
Open
chore(charts): sync SONIOX_API_KEY into backend secrets#12298mdmohsin7 wants to merge 2 commits into
mdmohsin7 wants to merge 2 commits into
Conversation
Git-on-my-level
approved these changes
Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
SONIOX_API_KEYexists in Secret Manager (org-level key, created 2025-05-17) and#12295 wired backend-listen to consume it, but the ExternalSecret enumerates its keys
explicitly and Soniox was not among the 34 listed. The key therefore never reaches the
cluster secret, so the binding resolves to nothing and Soniox can never be selected.
What changed
Adds the
SONIOX_API_KEY→SONIOX_API_KEYmapping to the prod and dev backendsecret charts, next to
MODULATE_API_KEYandDEEPGRAM_API_KEY.Verification
The org-level key was tested against the live Soniox service before this change:
authenticated, transcribed, and returned two distinct speakers on a two-speaker
sample. It is current, not stale.
The backend-listen binding is
optional: true, so pods start fine whether or not thekey is present; this change is what makes the provider actually usable.