Skip to content
Alle innlegg
Blog·6. mars 2026

Hvordan Screenshots Live Render API fungerer — En praktisk guide til App Store-automatisering

En teknisk gjennomgang av hvordan Screenshots Live render API behandler maler, bruker YAML-overstyringer og genererer butikk-klare skjermbilder — med virkelige kodeeksempler og CI/CD-mønstre for whitelabel-oppsett.

Hva denne artikkelen dekker

Hvis du leverer whitelabel-apper — eller til og med bare én app med flere butikkoppføringer — har du sannsynligvis møtt skjermbildeproblemet. Apple vil ha skjermbilder for hver enhetsstørrelse. Google Play vil ha sitt eget sett. Støtt tre språk og du har tredoblet arbeidsmengden din. Multipliser nå det med antall merkevarevarianter du vedlikeholder.

Den forrige artikkelen forklarte hvorfor Screenshots Live eksisterer. Denne er den praktiske oppfølgingen: hvordan render API er utformet, hva det forventer og hvordan man kobler det til bygge-pipelinen din slik at skjermbilder slutter å være en manuell oppgave.

Hvordan renderingspipelinen er utformet

Renderingssystemet er ikke et synkront send-forespørsel-motta-bilde-endepunkt. Det er en jobbbasert pipeline, noe som betyr noe når du renderer dusinvis eller hundrevis av skjermbilder i batch.

  1. Du sender inn en renderingsforespørsel med en mal-ID og valgfrie YAML-overstyringer.
  2. Validering — systemet sjekker at malen din eksisterer, at du eier den og at hvert felt du overstyrer faktisk er tillatt.
  3. Køing — jobben går inn i en Redis-støttet BullMQ-kø. API-anropet ditt returnerer umiddelbart med et jobId og statusen Pending.
  4. Rendering — en Rust-basert worker tar opp jobben, henter malen og bildene, renderer canvas med Skia og genererer utdata.
  5. Pakking — de renderede bildene pakkes til ZIP og lastes opp til objektlagring.
  6. Nedlasting — du poller statusendepunktet. Når det er Completed, treffer du nedlastingsendepunktet for en forhåndssignert URL (gyldig i 1 time).

Det asynkrone designet er bevisst. Når du trenger å rendere 50 maler for en release, avfyrer du dem alle og samler deretter inn resultater. Ingen blokkering, ingen tidsavbrudd.

Autentisering

Du trenger en Pro-konto for å få tilgang til render API. Opprett en API-nøkkel fra dashbordet ditt — den vil se ut som sa_live_.... Hver forespørsel bruker den som Bearer-token:

Authorization: Bearer sa_live_your_key_here

Maler: Hvordan de er strukturert

Alt dreier seg om maler. En mal er et canvas du bygger i den visuelle editoren. Hvert element på canvas er et item med en unik UUID. For automatisering er det kritiske konseptet byttbare felt — administrator konfigurerer hvilke felt som kan byttes ut: tekstinnhold, skriftfamilie, skriftstørrelse, farger, skjermbilde-URL-er, enhetsvindu-ID-er. Dette forhindrer at API-forbrukere ved et uhell bryter layouten ved å endre posisjoner eller størrelser designeren låste inn.

Tenk på det som en kontrakt mellom designeren og pipelinen: designeren eier layouten, pipelinen eier innholdet.

YAML-overstyringssystemet

Dette er kjernen i API-et. I stedet for å rendere en mal nøyaktig slik den er lagret, sender du POST med YAML som overstyrer spesifikke felt på spesifikke elementer.

Trinn 1: Hent YAML-stillaset

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

Trinn 2: Send inn 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: "Spor leveringene dine"
    color: "#1A73E8"'

Trinn 3: Poll statusen

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

Statusen skrider frem gjennom Pending til Completed (eller Failed). For de fleste maler tar renderingen noen sekunder.

Trinn 4: Last ned

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

Returnerer en forhåndssignert URL. Nedlastingen er en ZIP som inneholder de renderede bildene dine.

Direkte opplasting av skjermbilder

Du trenger ikke å være vert for skjermbildene dine et sted bare for å sende en URL. Endepunktet /render/api/with-pictures aksepterer multipart-opplastinger. Du kan legge ved opptil 200 filer, hver opptil 10 MB. Dette gjør API-et praktisk for CI/CD — pipelinen din fanger skjermbilder og du sender dem direkte til renderingen uten mellomliggende lagring.

Bytte enhetsvinduer

Enhetsvinduer er mockup-overlegg — iPhone 16 Pro, Pixel 9, iPad Air, Galaxy S24. De er forhåndslastet inn i kontoen din og refereres av UUID. Den samme malen kan renderes med ulike enhetsvinduer ved å overstyre frameId. Send to renderingsjobber — en med iPhone-ramme, en med Pixel-ramme — og du dekker begge butikker fra én mal.

Hastighetsbegrensninger og kvoter

  • Render API: 5 forespørsler per 60 sekunder
  • Statuspolling: 60 forespørsler per 60 sekunder
  • Daglige renderinger: 100 per dag på Pro-nivå
  • Bildeopplastinger: maks 200 filer per forespørsel, 10 MB hver

YAML-validering

YAML-parseren er bevisst streng: ingen ankere, ingen aliaser, ingen egendefinerte tagger, maks 1 MB. Feilmeldingen forteller deg nøyaktig hva som er galt — feil feltnavn, ikke-byttbart felt, ugyldig UUID-format, URL som peker til et privat IP-intervall. Det er utformet for å mislykkes raskt og tydelig, noe som betyr noe når du feilsøker en CI-pipeline kl. 23:00.