Build with Claude, ChatGPT, Cursor, or any LLM

Hand your API key to an LLM. Get screenshots and CI/CD.

Screenshots.live exposes a JSON Schema and OpenAPI spec at stable URLs. An LLM with your API key can create templates, place items, generate a GitHub Actions workflow, and trigger renders — without you writing a line of code.

How it works

  1. 1

    Create an API key

    Sign in and create a key in your dashboard. Copy it once (it begins with sa_live_) and store it as a secret. It authenticates both template creation and renders.

  2. 2

    Give the LLM the system prompt + your key

    Paste the system prompt below into Claude, ChatGPT, Cursor, or any agent. Add your spec — the screens you want, the copy, the device frame, your brand colors. The LLM reads the schema and POSTs templates and items on your behalf.

  3. 3

    Let the LLM write the workflow

    Ask for a GitHub Actions workflow. The LLM emits YAML that uses the official render-screenshots-action, references your secret, and produces a downloadable artifact every push.

Copy-paste system prompt

Drop this into the system field of any LLM tool. It points the model at the schema URLs and lays down the basic rules so it produces valid payloads instead of hallucinating fields.

prompt
You are an expert at creating Screenshots.live templates programmatically.

You have an API key for Screenshots.live (it begins with sa_live_). You can:

1. Read the JSON Schema for templates at:
   https://api.screenshots.live/schema/templates.json

2. Read the full OpenAPI specification at:
   https://api.screenshots.live/schema/openapi.json

3. Create templates by POSTing to https://api.screenshots.live/templates with the
   header: Authorization: Bearer <THE_API_KEY>

4. Add items (text, device frames, images, shapes, backgrounds) by POSTing to
   https://api.screenshots.live/templates/{id}/items

5. Render screenshots from a template by POSTing YAML to
   https://api.screenshots.live/render/api with the same Bearer header.

When the user describes a screenshot or asks for a CI/CD workflow:
- Fetch the schema first; do not invent fields.
- Use exact enum values from the schema for screenSizeCategory and item types.
- For coordinates and dimensions, stay within the screen size bounds.
- For CI workflows, prefer the official GitHub Action:
    uses: screenshots-live/render-screenshots-action@v1
- Never hard-code the API key in code; always reference a secret.

Always show the exact curl or YAML you executed, plus the response status,
so the user can audit what changed.

Machine-readable schema

Two stable URLs an LLM can fetch directly. The first is filtered to template-related shapes; the second is the full public OpenAPI spec for every endpoint your API key can use.

bash
curl https://api.screenshots.live/schema/templates.json | jq '.components.schemas | keys'

Endpoints LLMs use most

All endpoints accept your sa_live_ API key as a Bearer token. Templates and items belong to the key's owner; rate limits are tier-based.

MethodPathPurpose
POST/templatesCreate a template (defines canvas size and screen count).
GET/templatesList the API key owner's templates.
GET/templates/{id}Fetch a template with its items.
POST/templates/{id}/itemsAdd an item: Text, DeviceFrame, Image, Shape, CanvasBackground, or Html.
PUT/templates/{id}/items/{itemId}Update an item's position, z-index, or properties.
PUT/templates/{id}/items/bulkReplace all items in a template in one call.
POST/render/apiRender a template into screenshots from a YAML body.
GET/templates/{id}/yamlDownload a YAML scaffold with swappable fields ready to feed the render API.

Authentication

Send Authorization: Bearer sa_live_<your-key>. The same key authenticates template CRUD, item CRUD, and render dispatch — no separate scopes.

bash
curl -X POST https://api.screenshots.live/templates \
  -H "Authorization: Bearer $SCREENSHOTS_LIVE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Fitness app — launch screens",
    "screenSizeCategory": "Mobile",
    "screenCount": 3
  }'
bash
curl -X POST https://api.screenshots.live/templates/$TEMPLATE_ID/items \
  -H "Authorization: Bearer $SCREENSHOTS_LIVE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "Text",
    "x": 80,
    "y": 120,
    "zIndex": 10,
    "properties": {
      "text": "Track every workout",
      "fontSize": 64,
      "fontWeight": "bold",
      "color": "#0F172A",
      "textAlign": "left"
    }
  }'

Vocabulary an LLM should pin

These enums come straight from the schema. Pinning them in the system prompt keeps the model from inventing values that 422-fail.

Item types
TextDeviceFrameImageShapeCanvasBackgroundHtml
Screen size categories
MobileTabletDesktopCustom

Sample CI/CD workflow

An LLM that follows the prompt above will produce something like this. The action handles the YAML render call, error retries, and artifact upload.

yaml
name: Render screenshots
on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  screenshots:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Render via Screenshots.live
        uses: screenshots-live/render-screenshots-action@v1
        with:
          api-key: ${{ secrets.SCREENSHOTS_LIVE_API_KEY }}
          template-id: ${{ vars.SCREENSHOTS_TEMPLATE_ID }}
          yaml-path: ./screenshots/template.yaml

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: screenshots
          path: ./screenshots/output/

Add SCREENSHOTS_LIVE_API_KEY to repository secrets and SCREENSHOTS_TEMPLATE_ID to repository variables before pushing.

Errors LLMs should expect

Surface these to the LLM so it can recover instead of looping.

  • 401Missing or invalid Bearer token. Re-check the secret reference.
  • 403Tier limit hit (e.g. template count exceeded) or wrong owner. The LLM should not retry without changes.
  • 422Schema validation failed. The LLM should re-fetch the schema and re-validate before posting.
  • 429Rate limit exceeded. Back off and retry; tier-based limits apply per key.

Next steps