Skip to main content
POST
Rewrite text with AI post-processing

Authorizations

Authorization
string
header
required

Token from the discovery file. Required on every endpoint except /health.

Body

application/json
text
string
required
mode_id
string<uuid>
preset
string

hyper | message | mail | note | meeting | code | custom. Mutually exclusive with prompt.

prompt
string

Free-form system prompt. Sets preset=custom.

provider
string
model
string

Response

200 - application/json

Rewritten text or business error envelope

ok
boolean
text
string
provider
string

The provider that ACTUALLY ran, not the one stored on the mode. The SHAPE of this value is not the same on every head. macOS and Windows return a provider id (openai, anthropic, local_llm, or the custom:<uuid> string you configured); when the mode's stored spelling names the same provider, that spelling is echoed back unchanged, so the value differs from what you sent only when post-processing genuinely routed elsewhere. HyperWhisper Cloud has two accepted spellings for the one provider — macOS resolves it as hyperwhisper and Windows as hyperwhispercloud — and either can come back, because the spelling on your mode is preserved. Linux returns a HUMAN DISPLAY LABEL instead — OpenAI · gpt-5.6-luna, Local LLM · <file>.gguf · <runtime>, HyperWhisper Cloud · <engine> · <model> — so do not compare it against a provider id there. Windows returns none when post-processing was skipped; macOS then returns the provider the mode resolves to, which is not a claim about a run (read post_processed); Linux fails the request rather than returning a skipped body.

model
string

The model that ACTUALLY ran and produced this text, not the one stored on the mode. Post-processing substitutes silently at several layers, and the substituted id is what appears here: a retired or unknown model id is remapped to the provider default, a local run reports the GGUF that was loaded, a custom endpoint reports the model name that went on the wire, and a HyperWhisper Cloud run reports the engine's catalog model id rather than the unrelated model field stored on the mode. The value is always a model id from the same vocabulary you would send in a request — never a display label. ONE KNOWN GAP: the hosted HyperWhisper Cloud backend runs a fallback of its own (a 5xx retry on another provider, or a prompt-leakage reroute) and that substitution is NOT visible here — a rerouted hosted request still reports the engine you asked for, because the backend does not expose the model it served as an id. When NO model ran, this falls back to the model the mode's own engine would have used (the cloud engine for a HyperWhisper Cloud mode, not the mode's model field) and is not a claim about a run; it can be empty. post_processed: false on macOS and provider: none on Windows are what tell you that happened. An EMPTY value on a run that DID happen means the opposite of nothing: an LLM ran and no single model id names this text. That is a macOS and Windows case only, and the cause is a MIXED-MODEL run — dictated-paragraph segments post-processed by different models, so no one id names the combined text. (Those two heads can also report "" for a stored custom endpoint whose model name is blank, but only when its URL needs repair as well: a blank model on its own is rejected before the call, and saving an endpoint rejects both, so only an endpoint carried in from an older build or a backup is in that state.) Linux never emits it — it post-processes the whole text in one call, and it rejects a blank-model custom endpoint before the call rather than running it — so an empty model there is always the nothing-ran fallback above. Read post_processed / provider to tell an empty run value from an empty fallback; never read empty as "nothing ran".

preset
string

The preset the mode was resolved to. Never remapped, so this always matches the mode.

latency_ms
integer
post_processed
boolean

true when an LLM actually ran and produced post-processed text; false when a failure path returned the raw input unchanged. ok stays true for graceful degradation, so read this to know post-processing happened. Sent by every platform on every ok:true body; macOS decodes it as a non-optional Bool. Which failures degrade to ok:true and which answer an ok:false envelope instead still differs per platform — see the note on this endpoint.