Skip to content
Compresr docs

API reference

POST /compress/question-specific/stream

Server-Sent Events variant of the question-specific compression endpoint.

POST/api/compress/question-specific/streamAPI key

Server-Sent Events variant of the question-specific compression endpoint.

Same input as POST /compress/question-specific/, but the response is a Server-Sent Events stream instead of a JSON envelope. When to use it (and why plain compress usually wins today): streaming guide.

Request body

Identical to the non-streaming endpoint. latte_v2 accepts every parameter latte_v1 accepts, plus the three latte_v2-only dynamic* knobs (rejected on latte_v1 with 422).

Shared parameters (both models)

contextstringRequired
The text to compress.
querystringRequired
The question or topic to preserve relevance for.
compression_model_name"latte_v1" | "latte_v2"Required
Routes the call. See Models.
target_compression_rationumberOptional
Default: model default
Compression strength. See Models › target_compression_ratio. Ignored on latte_v2 when dynamic=true.
coarsebooleanOptional
Default: true
Paragraph-level compression (faster, less precise).
heuristic_chunkingbooleanOptional
Default: false
Pre-chunk with structure-aware heuristics.
disable_placeholdersbooleanOptional
Default: false
Drop the [...] markers between kept spans.

latte_v2-only parameters

dynamicbooleanOptional
Default: false
Picks the compression ratio per-input; overrides target_compression_ratio when true. Rejected on latte_v1 with 422.
dynamic_min_rationumberOptional
Default: model default
Floor on the chosen Nx ratio when dynamic=true. Must be ≥ 1.0.
dynamic_max_rationumberOptional
Default: model default
Ceiling on the chosen Nx ratio when dynamic=true. Must be ≥ 1.0.

Response

The response uses Content-Type: text/event-stream. Each event is a data: <json> frame. On success the server emits one content event carrying the full compressed output, then closes the stream:

text

If compression fails or times out (120s server-side budget) after the stream has opened, the server emits an error event instead, then closes:

text
Response
  • contentstring

    Compressed text. Currently the full output arrives in a single event; concatenate content across events to stay forward-compatible with incremental chunks.

  • doneboolean

    true on the final content event. The stream closes after it.

  • errorstring

    Present instead of content when the stream aborts mid-flight. The stream closes after it.

Status codes

Status codes
  • 200
    Stream opened. Body is text/event-stream.
  • 401
    Missing or invalid X-API-Key.
  • 422
    Field validation failure.
  • 429
    Rate limit hit.
  • 500
    Upstream error. Stream may include an error chunk before closing.
  • 503
    Upstream error. Stream may include an error chunk before closing.

The streaming endpoint returns events, not the standard response envelope, and it never returns the token-accounting metadata (original_tokens, compressed_tokens, tokens_saved, actual_compression_ratio, duration_ms). If you need those, use the non-streaming endpoint. Once the stream is open, failures arrive as an error event rather than an HTTP status. The SDK iterators skip that event, so an empty result is the only signal; the examples below treat it as a failure. Full handling, including retries, is in the streaming guide.

Request
python
Response
text