Website-Screenshots per API erstellen

Wählen Sie den kleinsten passenden API-Ablauf

Eine Screenshot-API kann mehrere Aufgaben erledigen. Vielleicht brauchen Sie ein Bild für einen Bericht, einen Render mit Headern und Cookies oder einen wiederholbaren visuellen Check mit Baseline und Prüfverlauf. Entscheiden Sie zuerst, welches Ergebnis gebraucht wird.

Die Website-Screenshot-API von RenderLog bietet drei praktische Wege. GET passt für eine schnelle Aufnahme per URL. POST passt für strukturierte Einstellungen. Einen gespeicherten Check starten Sie, wenn Baseline und Prüfverlauf von einer Person betreut werden sollen.

Erstellen und senden Sie ein Token sicher

Erstellen Sie im Workspace ein API-Token mit dem für den Endpoint nötigen Scope und bewahren Sie das Secret sicher auf. Senden Sie es im Header Authorization: Bearer rl_live_xxx. RenderLog prüft Token, Ablaufzeit und Scopes, bevor der Lauf startet. In den Workspace-Einstellungen kann ein Token widerrufen oder mit einem Ablaufdatum versehen werden.

Legen Sie ein Token nicht in eine URL oder in Browsercode. GET-Werte können in Logs, Browser-Historie oder Analytics auftauchen. Empfindliche Header und Cookies gehören deshalb in den POST-Body. Die API-Dokumentation beschreibt Authentifizierung und Felder pro Request.

Verwenden Sie für API-Aufrufe ein Workspace-Token statt einer Benutzersitzung.
Geben Sie runs:write zum Starten und runs:read zum Abfragen oder Lesen des Ergebnisses frei.
Senden Sie Secrets in unterstützten Headern oder POST-Feldern.
Rotieren oder widerrufen Sie ein Token bei Änderungen am aufrufenden System.

Nutzen Sie GET für eine einfache Aufnahme

Für eine öffentliche Seite ohne besondere Vorbereitung rufen Sie /api/render mit URL und optionalen Parametern auf. Der Request kann format, width, height, dpr, selector und fullPage enthalten. Eine URL kann codiert und mit format=png in einem stabilen Desktop-Viewport aufgenommen werden.

Die Antwort ist ein öffentlicher Job mit id, status und einem Ergebnis nach Abschluss. Das Ergebnis enthält Lauf- und Artefaktinformationen. GET passt, wenn URL und Optionen sicher in der Query stehen können und kein strukturierter JSON-Body nötig ist.

Codieren Sie die Ziel-URL vor dem Einfügen in die Query.
Verwenden Sie selector für ein Element und fullPage=true für die ganze Seite.
Halten Sie Breite, Höhe und Geräteskalierung bei Vergleichen stabil.
Prüfen Sie den Jobstatus, bevor Sie ein fertiges Artefakt annehmen.

Nutzen Sie POST für vollständige Render-Einstellungen

Verwenden Sie POST /api/render mit JSON, wenn Header, Cookies, User-Agent, Locale, Flow-Schritte, versteckte Selektoren oder Failure Rules nötig sind. Der Body akzeptiert eine URL und verwendet PNG als Standardformat. Er kann auch HTML oder Markdown rendern, wenn der entsprechende Inhalt gesendet wird. Ein einmaliger Render nutzt standardmäßig den RenderLog-Artefaktspeicher; rufen Sie die mit dem Job zurückgegebene Artefakt-URL ab, statt eine Storage-Einstellung im Request zu senden.

Ein praktischer POST-Body kann url, format, headers und failureRules enthalten. Failure Rules können einen Lauf als fehlerhaft markieren, wenn eine bekannte Challenge auftaucht oder ein benötigter Selektor fehlt. Ein technisch beendeter Browserlauf wird so nicht mit einem brauchbaren Seitenergebnis verwechselt.

Nutzen Sie JSON für Einstellungen, die lesbar und prüfbar bleiben sollen.
Verwenden Sie Header und Cookies nur für einen erlaubten Zielzustand.
Setzen Sie eine Missing-Selector-Regel für den nötigen App-Root.
Nutzen Sie async: true, wenn der Aufrufer den Job später abfragen soll.

Fragen Sie den Job ab und lesen Sie das Artefakt

Ein Render kann noch in der Warteschlange stehen oder laufen, bevor das Browserergebnis verfügbar ist. Fragen Sie GET /api/jobs/{id} mit demselben Bearer-Token ab, bis ein Endstatus erreicht ist. Dokumentierte Stati sind queued, running, passed, failed und canceled. Lesen Sie Ergebniszeilen und Artefakt-URLs erst nach dem Abschluss.

Speichern Sie die Job-ID zusammen mit Build, Bericht oder Datensatz, der sie angefordert hat. Die zurückgegebene Artefakt-URL ist der Nachweis für ein anderes System. Bei einem Fehler bewahren Sie Status und Details für die Analyse auf, statt blind zu wiederholen. Ein Retry kann einen weiteren abrechenbaren Lauf auslösen und die ursprüngliche Setup-Ursache verdecken.

Fragen Sie mit einem begrenzten Intervall ab und stoppen Sie bei Endstatus.
Behandeln Sie failed und canceled als Ergebnisse mit Handlungsbedarf.
Speichern Sie Job- und Lauf-ID neben Build oder Bericht.
Rufen Sie das Artefakt über die zurückgegebene URL ab.

Analysieren Sie Fehler und wählen Sie die nächste Ebene

Ein 401 bedeutet meist, dass das Bearer-Token fehlt, abgelaufen oder ungültig ist. Ein 403 kann auf runs:write zum Starten, runs:read zum Abfragen oder den Zugriff auf einen anderen Workspace hinweisen. Ein erfolgreicher Request mit fehlgeschlagenem Lauf weist auf Seitenzustand, Zugriff, Challenge oder ein fehlendes Ziel hin. Prüfen Sie Ergebnis und Einstellungen, bevor Sie die URL ändern.

Der Render-Endpoint erzeugt Seitennachweise. Wenn Baseline, wiederholbare Szenarien, Assertions oder visuelle Prüfung nötig sind, wechseln Sie zu einem gespeicherten Webtest und starten ihn über die API. Für ein einmaliges Bild bleibt der Ablauf klein. Die GET- und POST-Beispiele zeigen, wann die Request-Form wechseln sollte.