Programmatically read the content of existing gammas
B
Brigette Rouse
One thing that's blocking a more complete pipeline: there's currently no way to programmatically read the content of existing, human-edited gammas.
The API is entirely write-focused — you can generate, export what you just generated, and look up themes/folders. But if a human has edited a gamma directly (adding original insight, annotations, recommendations), that content is locked inside the platform with no programmatic exit.
We'd love to see:
- GET /v1.0/gammas— list gammas in a workspace
- GET /v1.0/gammas/{id}/content— retrieve slide/card text content as structured JSON or markdown
- Optionally: a webhook that fires on publish/save, pushing content to a URL we specify
A read API would make Gamma a proper node in an automation pipeline, not just a rendering endpoint. Would love to know if this is on the roadmap.
Nik Payne (Gamma design)
Brigette Rouse this is super thoughtful, and I totally get the “human-edited content is trapped” problem. Thanks for laying out the exact endpoints and webhook idea, I’ll pass this to the team.
Quick couple questions so we design the right thing:
1) For
GET /gammas/{id}/content
, what fidelity do you need beyond plain text (headings, speaker notes, tables, images, embeds, comments)?2) Is your main use case indexing/search (read-only) or round-tripping edits back into Gamma later?
3) For the webhook, would “published only” work, or do you need it on every save/draft change too?
Also, are there any tools you’re trying to connect this into (Zapier, Make, internal ETL, etc) so we can sanity check the format?
B
Brigette Rouse
Nik Payne (Gamma design) Hey Nik, I’ve answered the questions each in turn. Thanks for your quick response!
1. Headings, body text, and speaker notes as first-class fields. Tables as structured data. Images/embeds as typed placeholders with optional alt text. Comments not needed.
2. Read-only indexing — feeding into search and AI context (RAG pipelines). No write-back needed, at least not initially.
3. Every save, but debounced. Published-only misses too much. A status field (draft vs published) in the payload would let us filter on our end. Stable card IDs matter for incremental indexing.
4. Direct API and internal ETL. Not Zapier or Make.