Skip to content
OmniscapeRenders API
All pages
  1. Overview
  2. Quick start
  3. Authentication
  4. API reference
    1. GET /media
    2. POST /media
    3. GET /media/{id}/preview
    4. GET /integrations/google/connect
    5. GET /integrations/google
    6. DELETE /integrations/google
    7. GET /integrations/google/folders
    8. POST /media/import
    9. GET /media/imports/{id}
    10. POST /renders
    11. GET /renders/{id}
    12. GET /renders/{id}/download
    13. GET /usage
  5. Code examples
  6. Error handling
  7. Rate limits & quotas
  8. Troubleshooting
  9. Changelog

Overview

Renders API

Turn a photo and a line of text into a finished vertical video, programmatically. Six endpoints, one API key, no SDK. A render takes about 2 minutes, so everything here is built around starting one and collecting it later.

Read this first

Four things decide whether this API fits what you are building. They are up front because finding out on day three is worse than finding out now.

  • It is asynchronous, and slow on purpose. A render takes about 2 minutes. That is real generation work, the same work the product does in the browser — not queue latency you can tune away. Design for a job queue and a poll loop. A synchronous HTTP request will time out.
  • It renders one thing: a Pic to Video Render. A photo you already hold, plus a line of text, out as a vertical MP4 with the caption burned in. Slideshow Renders and video memes are not on the API in v1; asking for one is refused rather than silently substituted.
  • It takes your images as bytes, never as a URL. You can upload a photo over the API (POST /api/v1/media) or add it in the portal — either way you then render it by its media_id. What the API never accepts is a URL or path for it to go fetch; you send the image itself. You can also bulk-import a Google Drive folder you own — that takes a folder id, still never a URL, and reads only from Google. That is what keeps the surface safe to expose.
  • Nothing is pushed to you. There are no webhooks in v1. A finished render is something you poll for. Polling is free and uncounted, so poll on a sane interval and stop worrying about it.

Which plan you need

Two separate gates, and they do not line up — so the table says both. Holding a key is one question; having renders included is another.

PlanAPI keysRenders includedNotes
Freeno—Cannot hold an API key. Requests are 403 tier_not_eligible.
Starteryes0 per cycleA key works, but Pic to Video Renders are not included on this plan — every create is 402 quota_exceeded. Use it to build and test against the read endpoints; upgrade before you render.
Studioyes100 per cycleThe first plan that can actually render through the API.
Agencyyes500 per cycleSame surface, higher allowance.
CustomyesnegotiatedUncapped in code; the allowance is whatever your agreement says. Rate limits and spend caps are set per key.
On Starter, every create returns 402 quota_exceeded. The key is not broken and the request is not wrong — that plan simply includes no Pic to Video Renders. The read endpoints all work, so you can build and test the whole integration on Starter and upgrade when you are ready to render. Studio is the first plan with an allowance.

You do not need an account to read any of these pages. When you want a key, talk to us or mint one yourself on Settings → API.

What a key can and cannot do

Rendered from the same list the product shows on Settings → API, so this page and the product cannot disagree.

Can

  • Browse your media library. List the photos in your workspace with labels, tags and preview images, so an integration can pick one without anybody sending ids by hand.
  • Upload photos over the API. Push an image straight to your library from your own pipeline and get a media_id back to render — no portal step. The API takes the image bytes, never a URL, which is what keeps it safe to expose.
  • Start a Pic to Video Render. Submit a photo and a caption and get an opaque render id back immediately. Caption style, colour, size, weight and page theme are all settable per render.
  • Track it and collect the file. Poll a render for status and progress, then download the finished MP4 from a signed link when it completes.
  • Retry safely. Send an Idempotency-Key and a repeated request replays the original response instead of starting — and charging for — a second render.
  • Scope each key to a job. Keys carry explicit scopes, so a key that only reads renders cannot start one and a key that only browses media cannot spend.
  • Cap what a key can spend. Every key has its own daily spend ceiling, enforced server-side. A runaway integration stops at its own limit rather than yours.

Cannot, in v1

  • Pic to Video Renders only. Slideshow Renders and video memes are not on the API in v1. Asking for one is refused rather than silently substituted.
  • Renders take about 2 minutes. Generation is the slow part and it is the same work the portal does. Build around polling or a queue, not a synchronous request.
  • Everything is pulled, nothing is pushed. There are no webhooks yet, so a finished render is something you poll for rather than something we notify you about.

Where to go next