Vad den här artikeln täcker

Om du levererar whitelabel-appar — eller ens bara en app med flera butikslistningar — har du förmodligen stött på skärmdumpsproblemet. Apple vill ha skärmdumpar för varje enhetsstorlek. Google Play vill ha sin egen uppsättning. Stöd tre språk och du har trefaldigat din arbetsbelastning. Multiplicera nu det med hur många varumärkesvarianter du underhåller.

Föregående artikel förklarade varför Screenshots Live existerar. Den här är den praktiska uppföljningen: hur render API är utformat, vad det förväntar sig och hur man kopplar in det i din byggpipeline så att skärmdumpar slutar vara en manuell syssla.

Hur renderingspipelinen är utformad

Renderingssystemet är inte en synkron "skicka förfrågan, få bild"-endpoint. Det är en jobbbaserad pipeline, vilket spelar roll när du renderar dussintals eller hundratals skärmdumpar i batch.

Här är flödet:

Du skickar en renderingsförfrågan med ett mall-ID och valfria YAML-åsidosättningar (text, skärmdumpar, enhetsramar — allt som markerats som utbytbart).
Validering — systemet kontrollerar att din mall existerar, att du äger den och att varje fält du åsidosätter faktiskt är tillåtet. URL:er valideras mot privata IP-intervall och begränsade protokoll.
Köhantering — jobbet hamnar i en Redis-backed BullMQ-kö. Ditt API-anrop returnerar omedelbart med ett jobId och statusen Pending. Det här är nyckeln: du väntar inte på att renderingen ska slutföras.
Rendering — en Rust-baserad worker tar upp jobbet, hämtar mallen och bilderna (med LRU-cache för upprepade renderingar), laddar typsnitt, renderar canvas med Skia och genererar utdata.
Paketering — de renderade bilderna packas till ZIP och laddas upp till objektlagring.
Nedladdning — du pollar statusendpointen. När den är Completed anropar du nedladdningsendpointen för en försignerad URL (giltig i 1 timme).

Den asynkrona designen är avsiktlig. När du behöver rendera 50 mallar för en release avfyrar du dem alla, och samlar sedan in resultaten. Ingen blockering, inga timeouts.

Autentisering

Du behöver ett Pro-konto för att komma åt render API. Skapa en API-nyckel från din instrumentpanel — den ser ut som sa_live_.... Varje förfrågan använder den som Bearer-token:

Authorization: Bearer sa_live_your_key_here

Mallar: Hur de är strukturerade

Allt kretsar kring mallar. En mall är en canvas som du bygger i den visuella editorn — du placerar textblock, enhetsramar, bilder och ställer in bakgrunder. Varje element på canvas är ett item med ett unikt UUID.

För automatisering är det kritiska konceptet utbytbara fält. Inte alla egenskaper hos alla objekt är åsidosättbara via API:et. En administratör konfigurerar vilka fält som kan bytas ut — textinnehåll, typsnittsfamilj, teckenstorlek, färger, skärmdumps-URL:er, enhetsram-ID:n och så vidare. Det här är en avsiktlig begränsning: den förhindrar att API-konsumenter av misstag bryter layouten genom att ändra positioner eller storlekar som designern låste in.

Tänk på det som ett kontrakt mellan din designer och din pipeline: designern äger layouten, pipelinen äger innehållet.

YAML-åsidosättningssystemet

Det här är kärnan i API:et. Istället för att rendera en mall exakt som den är sparad postar du YAML som åsidosätter specifika fält på specifika objekt.

Steg 1: Hämta YAML-scaffolden

Varje mall har en scaffold-endpoint som returnerar alla utbytbara fält som kommenterad YAML:

curl -H "Authorization: Bearer sa_live_your_key_here" \
  https://api.screenshots.live/templates/YOUR_TEMPLATE_ID/yaml

Steg 2: Skicka in renderingen

curl -X POST https://api.screenshots.live/render/api \
  -H "Authorization: Bearer sa_live_your_key_here" \
  -H "Content-Type: text/yaml" \
  -d 'templateId: "550e8400-e29b-41d4-a716-446655440000"
items:
  - itemId: "7c9e6679-7425-40de-944b-e07fc1f90ae7"
    type: Text
    text: "Spåra dina leveranser"
    color: "#1A73E8"'

Steg 3: Polla statusen

curl -H "Authorization: Bearer sa_live_your_key_here" \
  https://api.screenshots.live/render/api/JOB_ID

Statusen fortskrider genom Pending → Active → Completed (eller Failed om något gick fel). För de flesta mallar tar renderingen några sekunder.

Steg 4: Ladda ner

curl -H "Authorization: Bearer sa_live_your_key_here" \
  https://api.screenshots.live/render/JOB_ID/download

Returnerar en försignerad URL. Nedladdningen är en ZIP som innehåller dina renderade bilder.

Direkt uppladdning av skärmdumpar

Du behöver inte vara värd för dina skärmdumpar någonstans bara för att skicka en URL. Endpointen /render/api/with-pictures accepterar multipart-uppladdningar. Du kan bifoga upp till 200 filer, vardera upp till 10 MB. Det här är vad som gör API:et praktiskt för CI/CD — din pipeline fångar skärmdumpar och du skickar dem direkt till renderingen utan att behöva mellanliggande lagring.

Byta enhetsramar

Enhetsramar är mockup-overlays — iPhone 16 Pro, Pixel 9, iPad Air, Galaxy S24. De är förladdade i ditt konto och refereras med UUID. Samma mall kan renderas med olika enhetsramar genom att åsidosätta frameId. Det här är hur du hanterar App Store vs Google Play-uppdelningen. Samma malllayout, samma skärmdump, annan ram.

Hastighetsgränser och kvoter

Render API: 5 förfrågningar per 60 sekunder
Statuspollning: 60 förfrågningar per 60 sekunder
Dagliga renderingar: 100 per dag på Pro-nivå
Bilduppladdningar: max 200 filer per förfrågan, 10 MB vardera

YAML-validering

YAML-parsern är avsiktligt strikt: inga ankare, inga alias, inga anpassade taggar, max 1 MB. Om något är fel berättar felmeddelandet exakt vad — fel fältnamn, icke-utbytbart fält, ogiltigt UUID-format, URL som pekar på ett privat IP-intervall. Det är utformat för att misslyckas snabbt och tydligt, vilket spelar roll när du felsöker en CI-pipeline kl. 23:00.