In SSE (Server-Sent Events) mode, the API does not wait for the model to finish before responding — it splits the result into a sequence of events. The response Content-Type is text/event-stream; each event starts with data: <JSON> and terminates with a blank line (\n\n). Events flow as head → chunk* → tail → meta; any failure replaces remaining events with an error event and closes the stream.

Event structure

The table below summarises the order and payload of all five event types. head, tail, and meta are mandatory (exactly one per stream); chunk appears zero or more times; error may surface at any moment and closes the stream once it does.

Client-side parsing

Two parsing paths are available: the browser's standard EventSource (GET only) or fetch + ReadableStream (supports POST + custom headers — required here, since this API is POST-only). The example below uses the fetch path: read the stream, split events by the blank-line delimiter, JSON.parse the data: line, and switch on type.

const res = await fetch("https://abemono.abestar.com.tw/api/v1/translations/text", {
    method: "POST",
    headers: {
        "X-API-Key": process.env.ABESTAR_API_KEY,
        "Content-Type": "application/json",
        Accept: "text/event-stream",
    },
    body: JSON.stringify({
        text: "今天的會議改到下午三點。",
        target_language: "en",
        stream: true,
    }),
});

const reader = res.body.getReader();
const decoder = new TextDecoder();
let buffer = "";
let output = "";

while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    buffer += decoder.decode(value, { stream: true });

    // Events are separated by a blank line; the last partial event stays in the buffer.
    const events = buffer.split("\n\n");
    buffer = events.pop() ?? "";

    for (const evt of events) {
        const dataLine = evt.split("\n").find((l) => l.startsWith("data: "));
        if (!dataLine) continue;
        const payload = JSON.parse(dataLine.slice(6));

        switch (payload.type) {
            case "head":
                console.log("source_lang:", payload.data.source_lang);
                break;
            case "chunk":
                output += payload.data;
                break;
            case "tail":
                console.log("output:", output);
                break;
            case "meta":
                console.log("usage:", payload.data.usage);
                break;
            case "error":
                console.error(payload.data.code, payload.data.request_id);
                break;
        }
    }
}

Mid-stream error handling

When an error or timeout occurs mid-stream, the server emits an error event and closes the stream. Chunks already received remain valid — the client decides whether to keep the partial result or discard everything. The error code matches the JSON-mode code (translation_failed, asr_timeout, content_policy_violation, and so on).

data: {
  "type": "error",
  "data": {
    "code": "translation_failed",
    "message": "Translation service temporarily unavailable",
    "details": {},
    "request_id": "0af7651916cd43dd8448eb211c80319c"
  }
}

Differences between ASR and translation

• head field name differs: translation uses source_lang, speech recognition uses detected_language.
• tail payload differs: translation's tail has no data; speech recognition's tail carries segments when timestamp_format is specified.
• meta payload differs: translation's meta carries only usage; speech recognition's meta also includes vocabulary_used and forced_replacement_count.
• Error code prefix differs: translation uses translation_*, speech recognition uses asr_* (asr_failed, asr_timeout, ...).
• Both endpoints are mutually exclusive with forced_replacement: sending stream=true and forced_replacement_dictionary_id together returns 400 validation_error before the stream starts.