Google Slides automation: Apps Script, the Slides API, and when to graduate to a platform

Three ways to automate Google Slides

Anyone trying to automate Google Slides ends up with one of three architectures. Each comes with different operational ergonomics and different ceilings.

1. Apps Script. JavaScript that runs inside Google's environment, with built-in OAuth and a high-level SlidesApp service. Free, low setup, ideal for small jobs.
2. The Google Slides API. REST API with batchUpdate semantics. Callable from any language. Requires OAuth, more careful setup, scales further than Apps Script.
3. Dedicated platforms. SourceToDocs, plus tools that wrap the Slides API behind a designer-friendly template model and an orchestration layer. Cost more in licence, save you the maintenance bill.

The architectures are not interchangeable. The right choice depends on volume, on who's going to maintain it, and on how much template fidelity matters. We cover the broader trade-offs in the document automation guide; this page focuses on the Slides-specific detail.

Apps Script: when it works, when it breaks

Apps Script is the right starting point when one engineer needs to automate one or two specific Google Slides workflows for a team that doesn't have, and won't soon have, dedicated automation infrastructure. The setup cost is near zero, the runtime is hosted by Google, and the SlidesApp service exposes most of what you need: getSlides, duplicateSlide, replaceAllText, insertImage, plus access to placeholders.

Where Apps Script breaks at scale:

• Execution time limits. Apps Script jobs cap at six minutes (or thirty for Workspace). Bulk runs that touch hundreds of decks need to chunk via triggers, which complicates the code.
• Master slide handling. When you duplicate a slide, the duplicate's relationship to the master can drift in subtle ways. Theme colours stop applying, font sizes get inlined, layouts get rewritten.
• Long strings. replaceAllText doesn't handle text that wraps across placeholder boundaries elegantly. The result is text that overflows or stretches the placeholder box.
• Concurrency. Apps Script runs single-threaded inside the trigger. High-volume parallel generation needs to coordinate via the Slides API, not Apps Script.

Healthy Apps Script implementations stay small (under 500 lines), have one clear owner, document their template assumptions explicitly, and have a known plan for what happens when the engineer who wrote them leaves the team.

The Google Slides API: capabilities and limits

The Slides API is what production-scale Google Slides automation runs on. It's a REST API with a single primary endpoint — presentations.batchUpdate — that takes a list of edit requests and applies them atomically.

Strengths

• Batch atomicity. A single batchUpdate call can do dozens of edits in one transaction. Either they all apply or none do.
• Language-agnostic. Callable from Python, Node, Go, anything that can speak HTTP and OAuth.
• Direct shape access. Insert text, images, tables; resize and reposition shapes; replace placeholder content.

Limits

• Quota. Per-user and per-project quotas. The default per-user quota is generous for individual workflows but constrains high-volume jobs. Plan for quota expansion if you're generating more than a few hundred decks per hour.
• BatchUpdate size. A single batch should not exceed roughly a thousand requests. Larger batches start to time out or get throttled.
• Master slide semantics. The API exposes layouts and masters, but mutating them mid-pipeline is fragile. Treat the master as immutable; mutate only the slides.
• Tables. Table edits via the API are unforgiving. Cell-by-cell text replacement works; structural changes (inserting rows / columns) require very careful request ordering.

Common automation patterns

Mail merge across rows

The "for each row in this spreadsheet, generate a deck" pattern. The clean implementation: copy the master template once per row, run a batchUpdate with replaceAllText requests for each placeholder, save the resulting deck. Variation: drive from Airtable rather than Sheets.

Dynamic slide insertion

The "for each session in this event, create one slide" pattern. The clean implementation: define a layout in the master named "session," call createSlide with that layout for each item, populate the placeholders. Don't copy from a content slide; you'll lose master fidelity.

Conditional sections

The "show this slide only when a flag is set" pattern. The clean implementation: keep all variants in the template, mark them with metadata, and call deleteObject on the slides that shouldn't appear in a given run. Cleaner than trying to insert sections from external sources.

Image insertion

Common, fiddly. The image must be public-readable or accessed via OAuth, and the API has rules about which sources it accepts. The pragmatic pattern: stage images in a Google Drive folder the script has access to, then reference them by Drive ID.

The template fidelity challenge

The single biggest difference between a good Slides automation and a brittle one is whether the master template survives. We discuss this architecturally in the document automation guide; the Slides-specific failure modes:

• Detached placeholders. When you copy a slide via Apps Script's duplicateSlide and then modify the copy, the placeholders sometimes lose their link to the layout. The text now lives as a free-floating shape; theme changes stop applying.
• Inlined formatting. replaceAllText can flatten formatting if the source text had multiple runs. The output text loses the bold or italic the designer intended.
• Resized text boxes. Long content stretches the placeholder rather than wrapping; the deck looks bad on a 16:9 screen.
• Theme drift. Direct shape edits can introduce inline colours that override the theme; the deck looks consistent in your editor but inconsistent when the brand team updates the theme.

Template-fidelity discipline: use createSlide with named layouts, never duplicate content slides; modify placeholder content, never resize placeholders; keep formatting in the master, never inline; and version-control the template so you can spot drift when it happens.

Working code examples

Apps Script: replace text in a copied template

// Copy a template, replace placeholders, return the new deck's ID.
function generateDeck(templateId, replacements) {
  const copy = DriveApp.getFileById(templateId).makeCopy();
  const presentation = SlidesApp.openById(copy.getId());
  for (const [key, value] of Object.entries(replacements)) {
    presentation.replaceAllText('{{' + key + '}}', String(value));
  }
  return copy.getId();
}

Slides API (Python): batch text replacement

from googleapiclient.discovery import build

slides = build('slides', 'v1')

def replace_text(presentation_id, replacements):
    requests = [
        {
            'replaceAllText': {
                'containsText': {'text': '{{' + key + '}}', 'matchCase': True},
                'replaceText': str(value),
            }
        }
        for key, value in replacements.items()
    ]
    return slides.presentations().batchUpdate(
        presentationId=presentation_id,
        body={'requests': requests}
    ).execute()

Slides API (Python): create a slide from a named layout

def add_session_slide(presentation_id, session):
    create_request = {
        'createSlide': {
            'slideLayoutReference': {'layoutId': SESSION_LAYOUT_ID},
            'placeholderIdMappings': [
                {'layoutPlaceholder': {'type': 'TITLE'},    'objectId': 'session_title'},
                {'layoutPlaceholder': {'type': 'BODY', 'index': 0}, 'objectId': 'session_speakers'},
            ]
        }
    }
    text_requests = [
        {'insertText': {'objectId': 'session_title', 'text': session['title']}},
        {'insertText': {'objectId': 'session_speakers', 'text': ', '.join(session['speakers'])}},
    ]
    slides.presentations().batchUpdate(
        presentationId=presentation_id,
        body={'requests': [create_request] + text_requests}
    ).execute()

The examples above are deliberately small — production code adds error handling, retries, structured logging, and template metadata. The point is to show the shape of clean Slides automation, not a finished deployment.

When to graduate from Apps Script to a platform

The signals that you've outgrown a script-only approach:

• The script crosses 500 lines and one person can no longer hold it in their head.
• The original engineer is leaving (or has left) and the team can't confidently modify the code.
• Volume is over 50 decks per run and execution-time limits are starting to bite.
• Multiple stakeholders need to edit the template and the script's assumptions about the template are getting brittle.
• You need to integrate with data sources beyond Sheets — Airtable, your warehouse, your CRM — and the script is sprouting authentication code.

If three or more are true, the maintenance liability of the script has crossed the licence cost of a platform. Time to make the move.

SourceToDocs for Google Slides

SourceToDocs runs Google Slides automation on top of the Slides API with the architectural commitments described above: createSlide with named layouts, never duplicate content; placeholder content modified, placeholders not resized; formatting kept in the master. Templates are authored in Slides by your designers; the platform respects the master and never re-renders.

The data layer connects to Airtable, Google Sheets, your warehouse, and arbitrary APIs. The orchestration layer schedules runs, routes outputs and keeps the audit trail. We pair Slides automation with our PowerPoint and Word automation pipelines so that the same data source can produce all three formats from one configuration.

SourceToDocs is a SaaS platform — billed monthly or yearly, with pricing scaled to the data connectors, Slides-specific features and output volume your workflow needs. Custom layout libraries, branded chart components and multi-language renderers all scope as part of the deployment. Standard tiers are coming soon; until then, see pricing for a tailored quote.

FAQ