Outputs
The five things a flow can produce, and what each costs to make.
A flow declares what it produces. There are five kinds:
| Kind | What it is |
|---|---|
screenshots | The captured frames, for embedding in articles and docs. |
gif | A silent looping animation of the same frames. Embeds anywhere an image does. |
interactive_demo | A clickable walkthrough of the captured screenshots. |
html_demo | The same walkthrough over the pages' real markup: sharp at any zoom, and self-contained enough to host yourself. |
video | A rendered video with spoken narration. The slowest and priciest to produce. |
Choose before recording, not after
The kind changes what has to be captured, not only what is rendered afterwards.
html_demo needs each page's real markup. A recording made for screenshots never gathered it, so
it cannot be promoted to an HTML demo without walking the flow again. This is the one ordering
mistake that costs a re-recording, which is why record takes --outputs.
screenshots, gif and interactive_demo all work from captured frames, so those three are
interchangeable after the fact.
HTML demos are served sandboxed
A captured page is your application's real markup, and serving it from our own origin would normally be the risk that blocks a feature like this.
Two layers handle it. The API sends Content-Security-Policy: sandbox; default-src 'none' for
text/html, and the player renders captures in a sandboxed iframe with no scripts, no forms, no
same-origin and no navigation. A public viewer inherits a capture that cannot act.