API Enhancement Requests: Editable Presentations and Improved Content Scaling for PowerPoint Export

Hi — two API limitations that are blocking us, both around adjusting presentations after they've been generated. Context: we generate presentations programmatically at volume through the API, as deliverables inside our own product. PROBLEM 1 — no way to edit an existing presentation via the API The API creates presentations but can't update them. So when we improve our house style, or spot a layout problem in something already generated, we have two options: regenerate it, which produces a new ID and URL and breaks the link already embedded in our product, or open each one in the editor and fix it by hand. For a handful that's fine. At our volume it isn't, and it means any styling improvement we make can only ever apply to future output, never to what we've already shipped to clients. What would solve it: an endpoint that applies an instruction to an existing presentation in place, keeping the same ID and URL — essentially the in-editor AI edit, exposed via the API. Even a restricted version limited to layout and styling, with content explicitly untouched, would cover most of our need. We've tested the equivalent prompt manually in the editor and it does exactly what we want; we just can't reach it programmatically. PROBLEM 2 — fixed card sizes shrink content instead of giving it more room, and we can't tune that from the API We need 16x9, because our clients export to PowerPoint. But with a fixed card height, dense slides get scaled down to fit rather than spread out, so text ends up small and cramped. Our worst example is a 25-slide presentation with five tables where almost every slide is visibly squashed. The auto-fit behaviour doesn't appear to be exposed as an API parameter at all — cardOptions only offers dimensions and headerFooter — so we can't influence it at generation time. Related: textOptions.amount is documented as applying only when textMode is generate or condense. We use preserve, because our copy is client-approved and must not be reworded. That leaves us no way to express "same words, spread across more slides." What would solve it: either expose the auto-fit / content-scaling behaviour as a generation parameter, or make textOptions.amount (or an equivalent density control) take effect alongside textMode: preserve. We know numCards and cardSplit: inputTextBreaks still work under preserve and we'll use them — but both require us to guess the right slide count up front, rather than letting Gamma lay content out well for the card size we've chosen. Happy to share specific examples if useful.