Skip to main content
Use synchronous generation when the caller can keep the HTTP connection open until the presentation is complete. The response includes the presentation identifier, exported file path, editor path, and credits consumed.
Use asynchronous generation for production jobs that should not depend on one long-running HTTP connection.

Before you begin

Create an API key in your Presenton account and store it in a secret manager. Send it with every request:
The Cloud v3 base URL is:

Generate from a prompt

Send a JSON body to POST /presentation/generate:

Choose the input

The generation request supports three useful input patterns: For file input, upload the documents first and pass the returned file values in files. See Generate from documents. For more control over the story, generate an outline before creating the presentation:
The outline endpoint returns an array of strings. Review or edit those strings, then pass them to slides:

Configure the result

Use one presentation design mode per request: select a standard_template for schema-backed standard layouts or a smart_design for Smart composition.

Handle the response

A successful request returns this shape:
  • Store presentation_id as the stable identifier for later operations.
  • Use path to retrieve the generated export.
  • Send a user to edit_path when they should review or refine the deck in Presenton Cloud.
  • Record credits_consumed for internal usage reporting when needed.

Export again after editing

If a user edits the presentation after generation, export the current version with POST /presentation/export:
  1. Validate the prompt, slide count, and uploaded files in your application.
  2. Generate and review an outline when narrative control matters.
  3. Select a standard template or Smart design and an optional theme.
  4. Submit the synchronous or asynchronous generation request.
  5. Store the returned presentation and task identifiers.
  6. Let a user review the result at edit_path when the workflow includes approval.
  7. Export the reviewed version and verify the downloaded file.

Handle failures

  • Treat every non-2xx response as a failed request and log its response body with secrets removed.
  • A 422 response means the payload does not satisfy the request schema; inspect the validation details before retrying.
  • Do not retry authentication or validation failures without changing the request.
  • Retry transient network or server failures with a bounded backoff and an application-level timeout.
  • Never log the Authorization header or expose the API key in client-side code.

Generate asynchronously

Queue long-running generation and monitor its task status.

Templates and themes

Discover valid design resources and apply them safely.