Korean captions on slam return 400: caption_hangul_text_latin_style

If you send Korean text to the slam, punch or tiktok-green caption styles, Sume returns 400 with caption_hangul_text_latin_style and does not create a job. Those styles use Latin display faces with no Hangul glyphs. The docs say a caption style you did not select is worse than an error, because the alternative is a video full of tofu boxes at the same price as a good video.

What to send instead

For Korean speech, the docs tell you to use one of the Hangul identities and not slam. If you send no style, Sume decides by the caption text: Korean text resolves to black-outline, and Latin text to slam. A style you select is always honored.

Two related refusals

The font rule mirrors the style rule. If you send a Hangul font with a Latin style, the API returns 400 with caption_font_requires_hangul_style. Both checks happen at request time, so you pay nothing for a render that would have been wrong.

Setting language: "ko" does not fix either error. The docs say language only tells speech-to-text which language to expect; it never selects a style or a font.

Handling it in code

If your pipeline captions mixed-language batches, route by the transcript's script, not by a fixed default. A Hangul-bearing line goes to a Hangul style; a Latin line can still use slam. The korean-ad style needs language: "ko" and supports Korean script_text. Since the error comes back before a job exists, a try-then-fallback loop is safe, and it is free.

Why an error beats a fallback

Many tools quietly swap the font when a glyph is missing. Sume's design choice is the opposite: the job is not created, the style is not changed, and the message names the problem. For an API consumer that is easier to test, since a given request either returns a job or a stable code.

The price also stays honest. A tofu-box video would cost the same $0.20 as a good one under the standalone estimate, so the check saves money as well as a reshoot.