fix(sdk): flatten createTranscription and createSpeech method signatures#366
Draft
charlesrockhead-OR wants to merge 3 commits intoOpenRouterTeam:mainfrom
Draft
Conversation
Add x-speakeasy-globals-hidden: true to the app-identification headers
(HTTP-Referer, X-OpenRouter-Title, X-OpenRouter-Categories) on
/audio/transcriptions and /audio/speech so they no longer count toward
x-speakeasy-max-method-params. Speakeasy still injects them from the SDK
constructor, but the per-call method signature stays flat — callers can
now write:
openrouter.stt.createTranscription({ model, inputAudio })
openrouter.tts.createSpeech({ model, input, voice })
instead of wrapping the body under { sttRequest: ... } / { speechRequest: ... }.
Scoped to STT/TTS only; all other endpoints keep their existing per-call
header override capability.
…atten-stt-tts-sigs # Conflicts: # .speakeasy/gen.lock # package.json
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.
Summary
openrouter.stt.createTranscription({ model, inputAudio })andopenrouter.tts.createSpeech({ model, input })did not compile against@openrouter/sdkv0.12.28 — the request body was wrapped under asttRequest/speechRequestfield, so callers had to write{ sttRequest: { model, inputAudio } }.This was caused by Speakeasy's
maxMethodParamsheuristic: STT and TTS each had 4 parameters (the request body plus 3 globally-injected app-identification headers —HTTP-Referer,X-OpenRouter-Title,X-OpenRouter-Categories). With 4 > the per-route override of 1 inx-speakeasy-max-method-params, Speakeasy collapsed everything into a single wrapper object, defeating the override.Fix
Add
x-speakeasy-globals-hidden: trueon the per-operation declarations of those headers for/audio/transcriptionsand/audio/speechonly, via the existingadd-headers.overlay.yaml. Per Speakeasy's docs, this hides the global from the per-call method signature while keeping it set via the SDK constructor. The body is then the only parameter Speakeasy counts, so it rides at the top of the method signature instead of being wrapped.API change
Same for
openrouter.tts.createSpeech.What's unchanged
HTTP-Referer / X-OpenRouter-Title / X-OpenRouter-Categoriesare still emitted on every STT/TTS request fromclient._options.httpReferer / appTitle / appCategories. Seesrc/funcs/sttCreateTranscription.tsandsrc/funcs/ttsCreateSpeech.ts— the header injection block is identical to before.new OpenRouter({ httpReferer, appTitle, appCategories })works exactly as before.chat.send,embeddings.generate,responses.send,guardrails.*,videoGeneration.generate, etc. still accept their existing wrapped request shape and still expose per-call header overrides.Breaking change for STT/TTS only
Anyone passing per-call header overrides to STT or TTS specifically (
createTranscription({ sttRequest, httpReferer: "..." })) will see a TS error — those headers must now be set on theOpenRouterconstructor. In practice these are app-identification headers that almost always come from constructor options, not from per-call overrides, so the impact should be small.Why an overlay (not a hand-written wrapper)
Hand-written wrappers around generated SDKs are explicitly disallowed for OpenRouter's generated SDKs. This change uses Speakeasy's own documented mechanism (
x-speakeasy-globals-hidden) and is contained to a single overlay file.