How Slidura works

Five steps, one loop. You stay in your normal PowerPoint workflow; Slidura handles everything between the template and the finished deck.

1. Upload your template

A .pptx from any version of PowerPoint, up to 50 MB. You can also attach a PDF export of the same deck in the same upload step — when a PDF is present, Slidura renders the real slide as the preview image in the fill builder instead of the wireframe fallback.

The template is stored exactly as uploaded. Slidura never edits it.

2. The catalog appears

A background job scans every slide and lists every fillable field — titles, body text, charts, tables, image placeholders, diagrams, code blocks, procedural-art shapes — in reading order. The theme palette is captured at the same time.

Optional: vision enrichment. If you enable it (requires a Gemini API key on your account), a second pass proposes field names and descriptions from the slide images. This is the one hosted-AI step on the catalog side, and it is always opt-in. The raw catalog is available immediately whether or not you use enrichment.

3. Annotate (or skip)

For each field you can rename it, add a description, set a character limit, and define allowed values or choice lists. Catalog-level head variables carry default values that are interpolated across the deck at submit time using {{name}} syntax.

This annotation becomes the brief your agent reads. A downloadable agent skill is available from the template workspace, so your agent arrives pre-wired to the right catalog.

Annotation is optional — skip it and iterate after you see the first build.

4. Fill it three ways

Slidura exposes three interfaces over the same build service:

• Your own agent over MCP or the JSON API. The build-lifecycle loop: create a build, write the fill (the service validates every field as you go), then start the build. MCP tools include get_catalog, create_build, submit_build, get_build_status, get_build_result, and search_refs for finding media. The JSON API (POST /api/v1/builds, etc.) covers the same surface for non-MCP clients.
• The web fill builder. A ref-search picker, typed input widgets, and a live slide preview per slide — a server-rendered SVG mock using the catalog’s field geometry, or the real slide image when a PDF was uploaded. Shapes in the preview are click-to-edit.
• The hosted build assistant (opt-in). A Gemini-powered chat tab on the fill builder that reads your brief, searches refs, and drafts the fill through the same validation path every external agent uses. Like enrichment, this is server-side AI and requires a Gemini API key; it is never on by default.

The build engine itself never runs AI. Rendering is pure compute: python-pptx + svgdeck. What the engine receives is a validated fill; how that fill was produced is up to you.

5. Build and download

Builds are durable objects with a lifecycle: created → started → built / failed → archived. A finished build produces a .pptx with your approved layouts unchanged and only the field contents replaced. You can reopen or copy any build later.

Charts and tables re-render with the new data you provided. Supported content types include charts, tables, images, icons, Mermaid diagrams, code blocks, and 35 procedural-art layouts (cycles, timelines, org charts, matrices, processes, funnels, and more — Slidura’s re-implementation of SmartArt as pure-compute geometry).

Failed builds refund the credit automatically.

What you don’t have to think about

• The .pptx ZIP format and OOXML internals.
• python-pptx, layouts, masters, or placeholder inheritance.
• Where to store templates, catalogs, and build outputs.
• Which slides to keep — the build engine handles slide selection from the fill you submit.
• Chart XML, table styles, or SVG-to-shape conversion.
• EU VAT on invoices (handled by Polar.sh at launch).

Request beta access