Eine Web-Scraping-Pipeline mit Zapier bauenDen Crawl anstoßen, den Callback auffangen, nicht mehr auf langsame Seiten warten

Ein Zap, der eine Seite scrapt, funktioniert meist beim ersten Versuch und fällt später aus. Das Muster ist bekannt: eine Webhooks by Zapier Aktion ruft einen Scraping-Endpunkt auf, wartet auf das HTML und übergibt es an eine Google Sheets-Zeile. Im Editor besteht sie den Test gegen eine schnelle Testseite. Dann trifft sie auf ein echtes Ziel, das hinter JavaScript rendert, hinter einer Challenge sitzt oder schlicht langsam antwortet, und die Aktion läuft in ihr Zeitlimit.

Der erste Impuls ist, die Anfrage verantwortlich zu machen. Die Anfrage ist in Ordnung. Das Problem ist, dass eine einzige Zapier-Aktion zwei Vorgänge mit sehr unterschiedlicher Lebensdauer offen hält: einen Workflow-Schritt im Sekundenbereich und einen Seitenabruf, der beliebig viel länger dauern kann, sobald das Ziel es so will.

Die Lösung besteht darin, das eine nicht mehr auf das andere warten zu lassen. Zapier stößt den Crawl an und ist fertig. Crawlbase führt den Crawl aus und meldet sich, sobald es etwas hat. Diese Anleitung baut genau diese Pipeline: zwei Zaps, kein Code und ein Wiederherstellungspfad für die Läufe, die schiefgehen.

Warum synchrones Scraping scheitert

Eine Zapier-Aktion hat ein endliches Ausführungsfenster. Für eine Automatisierungsplattform ist das eine vernünftige Entscheidung: Schritte sollen kurz sein, und eine Plattform, die Millionen davon ausführt, kann keinen einzelnen Schritt einen Platz unbegrenzt belegen lassen.

Der Abruf einer Webseite hält sich nicht an diese Erwartung. Wie lange eine Seite braucht, bestimmt das Ziel, nicht Sie. Eine Produktseite antwortet um 2 Uhr nachts vielleicht in 400 Millisekunden und braucht während eines Sales zwanzig Sekunden. Eine JavaScript-lastige Übersicht muss erst gerendert werden, bevor es überhaupt etwas zurückzugeben gibt. Eine Website unter Last, oder eine, die sich für eine Challenge entscheidet, kann einen Abruf weit über alles hinaus dehnen, womit ein Workflow-Schritt gerechnet hat.

Das Ergebnis ist ein Workflow, der weniger kaputt als unvorhersehbar ist. Er gelingt bei schnellen Seiten und läuft bei langsamen ins Timeout, scheitert also genau an den Zielen, für die sich die Automatisierung gelohnt hätte.

Wiederholungsversuche helfen nicht, denn ein Retry wiederholt dieselbe Kopplung an dasselbe Ziel. Auch das Aufteilen der URL-Liste in kleinere Batches hilft nicht, weil der Fehler pro Anfrage auftritt und nicht pro Volumen. Ändern muss sich die Form des Workflows: von anfragen, warten, verarbeiten zu anstoßen, crawlen, Callback, verarbeiten.

Die asynchrone Architektur

Die Crawlbase Crawling API unterstützt diese Trennung direkt. In ihrem synchronen Standardmodus bleibt die HTTP-Anfrage offen, bis die Seite fertig ist, und der Body kommt auf derselben Antwort zurück. Mit async=true nimmt die API den Auftrag stattdessen an, liefert sofort eine Request-ID (rid) und führt den Crawl im Hintergrund aus. Ergänzt man callback=<webhook URL> , teilt man ihr mit, wohin die fertige Seite gepostet werden soll.

Entscheidend ist hier der Unterschied zwischen Anfrage angenommen und Crawl abgeschlossen. Der Dispatcher erfährt immer nur das Erste. Die Seite selbst trifft bei einem anderen Zap ein, zu einem Zeitpunkt, den niemand geplant hat, und genau deshalb reagiert die Pipeline nicht mehr darauf, wie langsam das Ziel ist.

Zwei Details gehen leicht schief. Der Parameter heißt callback, nicht callback_url. Und für alles, was produktiv laufen soll, kombinieren Sie ihn mit store=true, was die Antwort in Crawlbase Cloud Storage unter derselben ridspeichert. Dieses eine Flag entscheidet darüber, ob ein verlorener Callback Sie eine Abfrage oder einen weiteren Crawl kostet.

Wenn Ihre Ziele schnell und unkompliziert sind, brauchen Sie nichts davon. Die native Crawlbase Zapier-Integration bietet Ihnen Crawl URL, Scrape Structured Dataund Take Screenshot als gewöhnliche Zap-Aktionen ganz ohne Webhook-Verkabelung. Greifen Sie zum Callback-Muster, wenn die Abrufzeit das ist, was Ihren Workflow zerlegt.

Bauen Sie den Receiver vor dem Dispatcher

Die beiden Zaps haben eine Abhängigkeit in der Baureihenfolge, über die viele stolpern. Der Catch Hook des Receivers erzeugt die URL, die der Dispatcher als callbackübergeben muss, also muss der Receiver zuerst existieren. Baut man den Dispatcher zuerst, hat man eine Crawl-Anfrage und keinen Ort für das Ergebnis.

Bevor Sie beginnen, brauchen Sie:

1. Ein Crawlbase-Konto. Registrieren Sie sich und kopieren Sie Ihr Crawling-API-Token aus dem Dashboard. Das Normal Token deckt die meisten Seiten ab; das JavaScript Token ist für Ziele gedacht, die Rendering brauchen.
2. Ein Zapier-Konto in einem Tarif, der mehrstufige Zaps erlaubt, denn beide Zaps hier sind mehrstufig.
3. Ein Ziel für die Daten: ein Google Sheet, ein Slack-Kanal, eine Airtable-Basis oder ein CRM.
4. Eine Test-URL. Nehmen Sie eine echte Seite aus dem Workflow, den Sie automatisieren, statt eines Platzhalters, damit die Zeiten, die Sie sehen, auch die Zeiten sind, die Sie bekommen.

Zap B: der Receiver

Der Receiver ist der Callback-Endpunkt. Er startet nie einen Crawl. Er wartet darauf, dass Crawlbase eine fertige Seite postet, und validiert und leitet sie dann weiter.

Schritt 1: den Catch Hook anlegen

Legen Sie in Zapier einen neuen Zap an und wählen Sie Webhooks by Zapier als Trigger mit dem Ereignis Catch Hook. Zapier erzeugt eine Custom Webhook URL , die so aussieht:

https://hooks.zapier.com/hooks/catch/1234567/abcdef/

Kopieren Sie sie. Das ist der Wert des Crawlbase-Parameters callback im Dispatcher, und sie ist das Einzige, was die beiden Hälften der Pipeline verbindet.

Schritt 2: eine Beispiel-Payload liefern

Zapier muss eine Anfrage gesehen haben, bevor es die Callback-Felder zum Mapping anbieten kann. Sie können die eigenen Testwerkzeuge nutzen oder selbst ein Beispiel posten. Ein echter Crawlbase-Callback trägt den gecrawlten Inhalt zusammen mit Metadaten, darunter rid, url, original_status und cb_status.

Gegen einen echten Callback zu mappen statt gegen ein erfundenes Beispiel ist die zusätzliche Minute wert. Feldnamen in einer handgeschriebenen Test-Payload passen erfahrungsgemäß nicht zu dem, was tatsächlich ankommt.

Schritt 3: die Verarbeitungsaktionen ergänzen

Sobald die Felder verfügbar sind, ergänzen Sie alles, was das Ergebnis validieren, transformieren und speichern soll. Formatter by Zapier übernimmt Trimmen, Teilstring-Extraktion und Splitten ohne Code. Eine Google Sheets: Create Spreadsheet Row Aktion könnte so mappen:

Google Sheets lässt sich am einfachsten überprüfen, aber das Ziel ist austauschbar: Slack, Salesforce, Airtable, Notion oder alles andere, womit Zapier sich verbindet. Keine dieser Aktionen läuft, während der Dispatcher offen ist, denn der Dispatcher war längst fertig, bevor der Callback eintraf.

Schritt 4: den Receiver einschalten

Veröffentlichen Sie den Receiver, bevor Sie eine einzige echte Async-Anfrage senden. Ein Catch Hook, der zu einem ausgeschalteten Zap gehört, verarbeitet nicht, was ihm geschickt wird, und ein Callback, der an einem deaktivierten Endpunkt ankommt, ist ein Crawl, den Sie bezahlt und weggeworfen haben. Den Receiver zuerst einzuschalten ist die günstigste Gewohnheit im ganzen Aufbau.

Zap A: der Dispatcher

Der Dispatcher nimmt eine URL aus einem bestehenden Workflow, reicht sie zum asynchronen Crawlen ein, notiert die ridund endet. Das ist die gesamte Aufgabe.

Schritt 1: den Trigger wählen

Der Trigger ist das, was in Ihrem Geschäft URLs erzeugt:

• Schedule by Zapier für wiederkehrende Preis- oder Verfügbarkeitsprüfungen
• Google Sheets: New Spreadsheet Row um eine URL zu crawlen, sobald sie einer Tabelle hinzugefügt wird
• Google Forms: New Response um eine URL zu crawlen, die jemand einreicht

Mappen Sie das Feld mit der vollständig qualifizierten URL, inklusive Schema.

Schritt 2: die Crawlbase-Anfrage ergänzen

Ergänzen Sie Webhooks by Zapier als Aktion mit dem Ereignis GETund setzen Sie die Request-URL auf https://api.crawlbase.com/. GET entspricht der Art, wie die Crawling API ihre Parameter dokumentiert. POST funktioniert ebenfalls, solange die Parameter unversehrt am Endpunkt ankommen.

Schritt 3: die Parameter konfigurieren

Ergänzen Sie unter Query String Paramsfünf Einträge:

Zwei Dinge sind zu beachten. Der Wert von url muss URL-kodiert sein, was vor allem zählt, wenn die Ziel-URL einen eigenen Query String trägt. Und das Token gehört in die Zap-Konfiguration und sonst nirgendwohin: halten Sie es aus Screenshots, geteilten Zap-Vorlagen und Support-Threads heraus, und rotieren Sie es, falls es doch nach außen gelangt.

Für Ziele, die Rendering brauchen, verwenden Sie das JavaScript Token und ergänzen die Rendering-Parameter wie page_wait, dokumentiert bei der Crawling API. Auch format=json ist eine Überlegung wert: es liefert Status, URL und Body als eine JSON-Hülle, was das Feld-Mapping im Receiver meist vereinfacht.

Die äquivalente Anfrage, falls Sie den Aufbau zuerst außerhalb von Zapier bestätigen wollen:

curl -G 'https://api.crawlbase.com/' \
  --data-urlencode 'token=YOUR_CRAWLBASE_TOKEN' \
  --data-urlencode 'url=https://example.com/product/123' \
  --data-urlencode 'async=true' \
  --data-urlencode 'callback=https://hooks.zapier.com/hooks/catch/1234567/abcdef/' \
  --data-urlencode 'store=true'

Das von Hand auszuführen ist ein guter Weg, ein Crawlbase-Problem von einem Zapier-Problem zu trennen, bevor beide verdrahtet sind.

Schritt 4: die Request-ID festhalten

Ergänzen Sie eine weitere Aktion, die die rid dauerhaft festhält, zusammen mit der Eingabe-URL und dem Zeitstempel der Übergabe. Eine Tabellenzeile genügt.

Das ist keine Buchhaltung um ihrer selbst willen. Die rid ist der Korrelationsschlüssel über alle drei Orte, an denen der Crawl existiert: die Übergabe, den späteren Callback und die gespeicherte Kopie. Sie ist es, womit Sie beantworten, ob eine URL schon gecrawlt wurde, ob ein Callback schon verarbeitet wurde und wohin ein fehlendes Ergebnis verschwunden ist.

Schritt 5: den Dispatcher einschalten

Veröffentlichen Sie ihn und widerstehen Sie der Versuchung, noch einen Schritt anzuhängen. Jede Aktion, die den Seiten-Body aus der Antwort des Dispatchers lesen will, führt genau das Warten wieder ein, das Sie gerade entfernt haben, und das Timeout kommt mit zurück. Die Antwort des Dispatchers enthält eine rid. Die Seite gehört dem Receiver.

Den Callback lesen: cb_status und original_status

Wenn der Crawl fertig ist, postet Crawlbase das Ergebnis an den Catch Hook. Nutzen Sie Test trigger nach einem echten Crawl, oder öffnen Sie einen aktuellen Zap-Lauf, und mappen Sie von dem, was tatsächlich ankam. Die Felder, auf die es ankommt:

• Der gecrawlte Inhalt, als HTML oder als geparstes JSON, wenn Sie einen Scraper angefordert haben
• cb_status, das Urteil von Crawlbase über den Crawl. 200 bedeutet Erfolg. Früher hieß es pc_status.
• rid, korreliert diesen Callback mit der Übergabe
• original_status, der HTTP-Status, den die Zielseite zurückgegeben hat
• url, die gecrawlte Seite

Die beiden Statusfelder beantworten unterschiedliche Fragen, und sie zu vermischen ist die häufigste Quelle schlechter Daten in einer solchen Pipeline. original_status beschreibt, was die Website gesagt hat. cb_status beschreibt, ob Crawlbase erfolgreich eine Antwort bekommen hat.

Setzen Sie also einen Filter by Zapier Schritt vor die Zielaktion und fahren Sie nur fort, wenn cb_status gleich 200ist. Alles danach sieht dann Seiten, die tatsächlich abgerufen wurden.

Halten Sie Parsing und Transport getrennt, wo es geht. Formatter by Zapier deckt gewöhnliche Textarbeit ab, und Code by Zapier ist da, wenn die Extraktion wirklich individuell ist. Für Websites, die Crawlbase bereits parst, liefert der Parameter scraper strukturiertes JSON und macht den Parsing-Schritt ganz überflüssig.

Den gesamten Ablauf einmal prüfen

Lassen Sie eine einzelne URL komplett durchlaufen, bevor Sie Volumen einschalten:

1. Prüfen Sie, dass der Receiver On ist und seine Catch-Hook-URL das ist, was der Dispatcher als callbacksendet.
2. Schalten Sie den Dispatcher auf On.
3. Lösen Sie den Trigger aus: fügen Sie die Testzeile hinzu, starten Sie den Zeitplan, senden Sie das Formular ab.
4. Prüfen Sie die Historie des Dispatchers. Die Webhooks-Aktion sollte schnell fertig sein und eine ridzurückgeben, keine Seite.
5. Geben Sie dem Crawl Zeit, fertig zu werden.
6. Prüfen Sie die Historie des Receivers auf den Callback-Lauf.
7. Prüfen Sie am Ziel die Zeile, die Nachricht oder den Datensatz.

Wenn der Dispatcher gelingt und der Receiver nie läuft, gibt es drei übliche Ursachen: die callback URL ist falsch oder enthält einen Tippfehler, der Receiver war ausgeschaltet, als Crawlbase zustellen wollte, oder ein Filter-Schritt hat den Lauf verworfen, bevor er die Zielaktion erreicht hat. Prüfen Sie in dieser Reihenfolge.

Cloud Storage als Wiederherstellungspfad

Callbacks sind der normale Zustellweg. Produktivsysteme brauchen eine Antwort für die Fälle, in denen das Normale nicht passiert: der Receiver war gerade in Bearbeitung, eine Ziel-App war ausgefallen, ein Filter war falsch und hat ein gutes Ergebnis verworfen.

Genau das bringt store=true . Die Antwort wird in Crawlbase Cloud Storage unter der ridgespeichert, sodass ein fehlgeschlagener Callback zu einem Abruf statt zu einem erneuten Crawl wird. Für gelegentliche Wiederherstellung schlagen Sie den Crawl über die rid im Storage-Dashboardnach. Für alles Wiederkehrende bauen Sie einen dritten kleinen Zap:

Der Storage lässt sich auch über url statt über ridabfragen, was die zuletzt gespeicherte Version dieser Seite liefert. Eine Grenze, um die herum Sie planen sollten: gespeicherte Seiten werden standardmäßig 14 Tage aufbewahrt. Cloud Storage ist ein Wiederherstellungspuffer, kein Archiv, also sollte alles, was Sie langfristig brauchen, vom Receiver in Ihr eigenes System kopiert werden.

Überlegungen für den Produktivbetrieb

Die Pipeline oben ist ein funktionierender Proof of Concept. Eine Handvoll Ergänzungen macht daraus etwas, das Sie laufen lassen können.

Machen Sie den Receiver idempotent. Behandeln Sie die rid als eindeutigen Schlüssel und prüfen Sie vor dem Schreiben, ob Sie sie bereits verarbeitet haben. Zustellversuche, ein manuell wiederholter Lauf oder ein mitten im Betrieb bearbeiteter Zap können denselben Callback zweimal durchlaufen lassen, und eine doppelte Zeile lässt sich viel leichter verhindern als bereinigen.

Validieren Sie, bevor Sie schreiben. Filtern Sie auf cb_statusund behandeln Sie alles andere als Ausnahme mit einem festen Ort, sei es eine eigene Tabelle, ein Slack-Alert oder eine Retry-Liste. Stille Fehler in einer Automatisierung sind schlimmer als laute, weil niemand hinsieht, bis die Daten schon falsch sind.

Halten Sie den Dispatcher blockierungsfrei. Er reicht ein und notiert. Jedes Mal, wenn jemand "nur einen kleinen Schritt" ergänzt, der den Body liest, kommt das Timeout zurück.

Schützen Sie das Token. Es lebt in der Zap-Konfiguration, nicht in Screenshots oder geteilten Vorlagen. Rotieren Sie es, wenn es nach außen gelangt.

Nehmen Sie das günstigste Token, das funktioniert. Das Normal Token ist schneller und kostet weniger als das JavaScript Token. Stufen Sie ein Ziel erst dann auf das JS Token hoch, wenn die Normal-Antwort leer oder von einer Challenge blockiert zurückkommt, nicht vorsorglich.

Respektieren Sie das Ziel. Prüfen Sie Nutzungsbedingungen, robots-Direktiven und Rate Limits und halten Sie sich daran. Dass die Automatisierung leicht zu bauen ist, ändert nichts daran, was Sie erheben dürfen.

Wo dieses Muster passt

Die Form aus Übergabe und Callback ist nicht spezifisch für Scraping. Zu ihr greifen Sie immer dann, wenn ein Workflow etwas Langsames anstoßen muss, ohne darauf zu warten.

Die Geschäftslogik ändert sich; das Ausführungsmodell nicht. Ein Geschäftsereignis startet einen asynchronen Crawl, ein Callback liefert das Ergebnis, und eine nachgelagerte Aktion macht etwas damit. Wenn Sie die Empfangsseite lieber in Code besitzen als in Zapier, ist dieselbe Architektur in Python beschrieben unter einen Flask-Callback-Server bauen.

Fazit

Das Problem am synchronen No-Code-Scraping war nie die HTTP-Anfrage. Es war die Kopplung der Lebensdauer eines Workflow-Schritts an die Lebensdauer eines Seitenabrufs, zwei Dinge, die keinen Grund haben, sich über ihre Dauer einig zu sein.

Die Trennung entfernt diese Abhängigkeit. Der Dispatcher sendet async=true und eine callback URL, erhält eine ridund ist in der Zeit einer Bestätigung fertig. Crawlbase crawlt nach eigenem Zeitplan und postet die Seite an den Receiver, der sie validiert und weiterleitet. Mit store=true sind die Läufe, die trotzdem schiefgehen, über die rid wiederherstellbar statt verloren.

Am Ende steht eine Pipeline, deren Zuverlässigkeit nicht mehr davon abhängt, wie schnell das langsamste Ziel gerade sein möchte.

Häufig gestellte Fragen (FAQ)

Kann ich Crawlbase mit Zapier ohne Code nutzen?

Ja. Die Pipeline in dieser Anleitung nutzt Webhooks by Zapier zum Senden der Anfrage und einen Catch Hook zum Empfangen des Ergebnisses, mit Formatter- und Filter-Schritten zur Verarbeitung. Kein Python und kein Backend nötig. Wenn Ihre Ziele schnell genug sind, dass Sie Async gar nicht brauchen, bietet die native Crawlbase Zapier-App Crawl URL, Scrape Structured Data und Take Screenshot als fertige Aktionen.

Warum asynchrones Crawling mit Zapier statt einer normalen Anfrage?

Weil eine Zapier-Aktion ein endliches Ausführungsfenster hat und ein Seitenabruf nicht. Mit async=true ist die auslösende Aktion fertig, sobald Crawlbase den Auftrag annimmt und eine ridzurückgibt, sodass eine langsame oder aufwendig gerenderte Seite nicht mehr darüber entscheidet, ob der Zap überlebt. Die fertige Seite trifft separat beim Receiver ein.

Was ist der Unterschied zwischen cb_status und original_status?

cb_status ist das Urteil von Crawlbase über den Crawl, wobei 200 Erfolg bedeutet. Früher hieß es pc_status. original_status ist der HTTP-Status, den die Zielseite zurückgegeben hat. Sie sind unabhängig voneinander: eine Website kann mit 404 antworten und trotzdem erfolgreich gecrawlt worden sein, und eine Challenge-Seite kann mit 200 antworten, während der Crawl selbst fehlgeschlagen ist. Verzweigen Sie Ihren Workflow über cb_status.

Was passiert, wenn der Zapier-Callback fehlschlägt?

Wenn die Anfrage store=trueenthielt, wurde die Antwort im Crawlbase Cloud Storage unter ihrer ridgespeichert, sodass Sie sie über das Storage-Dashboard oder einen kleinen Wiederherstellungs-Zap abrufen können, statt die Seite erneut zu crawlen. Genau deshalb hält man jede rid bei der Übergabe fest. Gespeicherte Seiten werden standardmäßig 14 Tage aufbewahrt.

Kann ich diese Pipeline auf jeder Website betreiben?

Ja. Der asynchrone Modus funktioniert auf jeder Domain, die Pipeline ist also nicht an bestimmte Ziele gebunden. Unterschiedlich ist, was das jeweilige Ziel braucht: Seiten, die clientseitig rendern, wollen das JavaScript Token und manchmal page_wait, und manche Websites sind schlicht langsamer als andere, was genau das Problem ist, das diese Architektur abfängt. Prüfen Sie Nutzungsbedingungen, robots-Direktiven und Rate Limits der Website, bevor Sie einen geplanten Zap darauf richten.

NZ

Neil Zamora

Senior Architect · Crawlbase

Senior Architect bei Crawlbase mit Fokus auf den Systemen hinter großflächigem Crawling: Proxy-Rotation, Anti-Bot-Resilienz und den APIs, die diese Komplexität verbergen.