Construire un pipeline de web scraping avec ZapierLancer le crawl, récupérer le callback, ne plus attendre les pages lentes

Un Zap qui scrape une page fonctionne en général du premier coup, puis se met à échouer. Le schéma est classique : une action Webhooks by Zapier appelle un point de terminaison de scraping, attend le HTML et le remet à une ligne Google Sheets. Elle passe dans l'éditeur face à une page de test rapide. Puis elle rencontre une vraie cible qui s'affiche derrière du JavaScript, se cache derrière un challenge ou répond simplement lentement, et l'action arrive au bout de son temps.

Le réflexe est d'incriminer la requête. La requête n'a rien. Le problème, c'est qu'une seule action Zapier maintient ouvertes deux opérations aux durées de vie très différentes : une étape de workflow qui se compte en secondes, et une récupération de page qui peut durer bien plus longtemps dès que la cible en décide ainsi.

La solution consiste à cesser de faire attendre l'une pour l'autre. Zapier lance le crawl et se termine. Crawlbase exécute le crawl et rend compte quand il a quelque chose. Ce guide construit ce pipeline avec deux Zaps, sans code, et un chemin de récupération pour les exécutions qui tournent mal.

Pourquoi le scraping synchrone finit par casser

Une action Zapier dispose d'une fenêtre d'exécution finie. C'est un choix raisonnable pour une plateforme d'automatisation : les étapes sont censées être courtes, et une plateforme qui en exécute des millions ne peut laisser aucune étape occuper un créneau indéfiniment.

La récupération d'une page web ne respecte pas cette attente. Le temps de chargement est fixé par la cible, pas par vous. Une fiche produit peut répondre en 400 millisecondes à 2 h du matin et prendre vingt secondes pendant les soldes. Une liste chargée en JavaScript doit être rendue avant qu'il y ait quoi que ce soit à renvoyer. Un site sous charge, ou qui décide de servir un challenge, peut étirer une récupération bien au-delà de ce qu'une étape de workflow avait prévu.

Le résultat est un workflow moins cassé qu'imprévisible. Il réussit sur les pages rapides et expire sur les lentes, donc il échoue précisément sur les cibles qui méritaient d'être automatisées.

Réessayer n'aide pas, car un retry reproduit le même couplage avec la même cible. Découper la liste d'URL en lots plus petits non plus, puisque l'échec est par requête et non par volume. Ce qui doit changer, c'est la forme du workflow : de requête, attente, traitement vers envoi, crawl, callback, traitement.

L'architecture asynchrone

L' API de crawl Crawlbase prend directement en charge cette séparation. Dans son mode synchrone par défaut, la requête HTTP reste ouverte jusqu'à ce que la page soit prête et le corps revient sur cette même réponse. Avec async=true l'API accepte au contraire la tâche, renvoie immédiatement un identifiant de requête (rid) et exécute le crawl en arrière-plan. En ajoutant callback=<webhook URL> , vous lui indiquez où poster la page terminée.

La distinction qui compte ici est celle entre requête acceptée et crawl terminé. Le Dispatcher n'apprend jamais que la première. La page elle-même arrive sur un autre Zap, à un moment que personne n'a planifié, et c'est exactement pour cela que le pipeline cesse d'être sensible à la lenteur de la cible.

Deux détails sont faciles à manquer. Le paramètre est callback, pas callback_url. Et pour tout ce que vous comptez exécuter en production, associez-le à store=true, qui enregistre la réponse dans Crawlbase Cloud Storage sous le même rid. Ce seul indicateur fait la différence entre un callback perdu qui vous coûte une consultation et un qui vous coûte un second crawl.

Si vos cibles sont rapides et simples, vous n'avez besoin de rien de tout cela. L' intégration Zapier native de Crawlbase vous donne Crawl URL, Scrape Structured Dataet Take Screenshot comme actions Zap ordinaires, sans aucune plomberie de webhook. Réservez le motif callback au cas où c'est le temps de récupération qui casse votre workflow.

Construisez le receiver avant le dispatcher

Les deux Zaps ont une dépendance d'ordre de construction qui prend beaucoup de monde au dépourvu. Le Catch Hook du Receiver génère l'URL que le Dispatcher doit passer en callback, donc le Receiver doit exister en premier. Commencer par le Dispatcher vous laisse avec une requête de crawl et nulle part où envoyer le résultat.

Avant de commencer, il vous faut :

1. Un compte Crawlbase. Inscrivez-vous et copiez votre token de l'API de crawl depuis le tableau de bord. Le Normal token couvre la plupart des pages ; le JavaScript token est destiné aux cibles qui nécessitent un rendu.
2. Un compte Zapier sur une formule qui autorise les Zaps multi-étapes, puisque les deux Zaps présentés ici le sont.
3. Une destination pour les données : une feuille Google Sheets, un canal Slack, une base Airtable ou un CRM.
4. Une URL de test. Prenez une vraie page du workflow que vous automatisez plutôt qu'un substitut, pour que les temps que vous observez soient ceux que vous aurez.

Zap B : le receiver

Le Receiver est le point de terminaison du callback. Il ne démarre jamais de crawl. Il attend que Crawlbase poste une page terminée, puis la valide et l'achemine.

Étape 1 : créer le Catch Hook

Dans Zapier, créez un nouveau Zap et choisissez Webhooks by Zapier comme déclencheur, avec l'événement Catch Hook. Zapier génère une Custom Webhook URL qui ressemble à ceci :

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

Copiez-la. C'est la valeur du paramètre Crawlbase callback dans le Dispatcher, et c'est la seule chose qui relie les deux moitiés du pipeline.

Étape 2 : lui fournir une charge utile d'exemple

Zapier doit avoir vu une requête avant de pouvoir proposer les champs du callback pour le mappage. Vous pouvez utiliser ses propres outils de test, ou poster un exemple vous-même. Un vrai callback Crawlbase transporte le contenu crawlé accompagné de métadonnées dont rid, url, original_status et cb_status.

Mapper sur un vrai callback plutôt que sur un exemple inventé vaut la minute supplémentaire. Les noms de champs d'une charge utile écrite à la main ont tendance à ne pas correspondre à ce qui arrive réellement.

Étape 3 : ajouter les actions de traitement

Une fois les champs disponibles, ajoutez tout ce qui doit valider, transformer et enregistrer le résultat. Formatter by Zapier gère le nettoyage, l'extraction de sous-chaînes et le découpage sans code. Une action Google Sheets: Create Spreadsheet Row pourrait mapper :

Google Sheets est le plus simple à vérifier, mais la destination est interchangeable : Slack, Salesforce, Airtable, Notion ou tout autre service auquel Zapier se connecte. Aucune de ces actions ne s'exécute pendant que le Dispatcher est ouvert, car le Dispatcher avait terminé bien avant l'arrivée du callback.

Étape 4 : activer le receiver

Publiez le Receiver avant d'envoyer la moindre vraie requête asynchrone. Un Catch Hook appartenant à un Zap désactivé ne traitera pas ce qu'on lui envoie, et un callback qui arrive sur un point de terminaison désactivé est un crawl que vous avez payé et jeté. Activer le Receiver en premier est l'habitude la moins coûteuse de toute cette construction.

Zap A : le dispatcher

Le Dispatcher prend une URL depuis un workflow existant, la soumet au crawl asynchrone, enregistre le rid, et se termine. C'est tout son travail.

Étape 1 : choisir le déclencheur

Le déclencheur est ce qui produit des URL dans votre activité :

• Schedule by Zapier pour des contrôles récurrents de prix ou de disponibilité
• Google Sheets: New Spreadsheet Row pour crawler une URL dès qu'elle est ajoutée à une feuille
• Google Forms: New Response pour crawler une URL soumise par quelqu'un

Mappez le champ contenant l'URL pleinement qualifiée, protocole compris.

Étape 2 : ajouter la requête Crawlbase

Ajoutez Webhooks by Zapier comme action, avec l'événement GET, et réglez l'URL de la requête sur https://api.crawlbase.com/. GET correspond à la façon dont l'API de crawl documente ses paramètres. POST fonctionne aussi, tant que les paramètres arrivent intacts au point de terminaison.

Étape 3 : configurer les paramètres

Sous Query String Params, ajoutez cinq entrées :

Deux points de vigilance. La valeur de url doit être encodée pour URL, ce qui compte surtout quand l'URL cible porte sa propre chaîne de requête. Et le token appartient à la configuration du Zap et à rien d'autre : gardez-le hors des captures d'écran, des modèles de Zap partagés et des fils de support, et faites-le tourner s'il finit par sortir.

Pour les cibles qui nécessitent un rendu, utilisez le JavaScript token et ajoutez les paramètres de rendu, comme page_wait, documentés avec l' API de crawl. Ajouter format=json mérite aussi réflexion : cela renvoie le statut, l'URL et le corps dans une seule enveloppe JSON, ce qui simplifie généralement le mappage des champs dans le Receiver.

La requête équivalente, si vous voulez d'abord confirmer la configuration en dehors de Zapier :

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'

L'exécuter à la main est un bon moyen de séparer un problème Crawlbase d'un problème Zapier avant de câbler les deux ensemble.

Étape 4 : enregistrer l'identifiant de requête

Ajoutez une action de plus qui écrit le rid quelque part de durable, avec l'URL d'entrée et l'horodatage de l'envoi. Une ligne de feuille de calcul suffit.

Ce n'est pas de la comptabilité pour la forme. Le rid est la clé de corrélation entre les trois endroits où le crawl existe : l'envoi, le callback à venir et la copie stockée. C'est ce qui vous permet de répondre si une URL a déjà été crawlée, si un callback a déjà été traité et où est passé un résultat manquant.

Étape 5 : activer le dispatcher

Publiez-le, et résistez à l'envie d'ajouter une étape de plus. Toute action qui tente de lire le corps de la page depuis la réponse du Dispatcher réintroduit l'attente que vous venez de supprimer, et le timeout revient avec elle. La réponse du Dispatcher contient un rid. La page appartient au Receiver.

Lire le callback : cb_status et original_status

Quand le crawl se termine, Crawlbase poste le résultat sur le Catch Hook. Utilisez Test trigger après un vrai crawl, ou ouvrez une exécution récente du Zap, et mappez à partir de ce qui est réellement arrivé. Les champs qui comptent :

• Le contenu crawlé, en HTML ou en JSON déjà analysé si vous avez demandé un scraper
• cb_status, le verdict de Crawlbase sur le crawl. 200 signifie succès. Il s'appelait autrefois pc_status.
• rid, qui met ce callback en relation avec l'envoi
• original_status, le statut HTTP renvoyé par le site cible
• url, la page qui a été crawlée

Les deux champs de statut répondent à des questions différentes, et les confondre est la source la plus fréquente de mauvaises données dans un pipeline de ce type. original_status décrit ce qu'a dit le site. cb_status décrit si Crawlbase a effectivement obtenu une réponse.

Placez donc une étape Filter by Zapier devant l'action de destination et ne continuez que lorsque cb_status vaut 200. Tout ce qui suit ne voit alors que des pages réellement récupérées.

Séparez l'analyse du transport autant que possible. Formatter by Zapier couvre le travail textuel ordinaire, et Code by Zapier est là quand l'extraction est vraiment sur mesure. Pour les sites que Crawlbase analyse déjà, le paramètre scraper renvoie du JSON structuré et supprime complètement l'étape d'analyse.

Vérifier tout le flux une fois

Faites passer une seule URL de bout en bout avant de monter en volume :

1. Vérifiez que le Receiver est sur On et que l'URL de son Catch Hook est bien ce que le Dispatcher envoie en callback.
2. Passez le Dispatcher sur On.
3. Déclenchez : ajoutez la ligne de test, lancez la planification, soumettez le formulaire.
4. Consultez l'historique du Dispatcher. L'action Webhooks doit se terminer rapidement et renvoyer un rid, pas une page.
5. Laissez au crawl le temps de se terminer.
6. Consultez l'historique du Receiver pour l'exécution du callback.
7. Vérifiez la destination : la ligne, le message ou l'enregistrement.

Si le Dispatcher réussit et que le Receiver ne s'exécute jamais, il y a trois causes habituelles : l'URL de callback est erronée ou comporte une faute de frappe, le Receiver était désactivé quand Crawlbase a tenté la livraison, ou une étape Filter a écarté l'exécution avant qu'elle n'atteigne l'action de destination. Vérifiez dans cet ordre.

Cloud Storage comme chemin de récupération

Les callbacks sont le chemin de livraison normal. Les systèmes en production ont besoin d'une réponse pour les fois où le normal ne se produit pas : le Receiver était en cours de modification, une application de destination était tombée, un filtre erroné a écarté un bon résultat.

C'est ce qu'apporte store=true . La réponse est enregistrée dans Crawlbase Cloud Storage sous le rid, de sorte qu'un callback perdu devient une récupération et non un nouveau crawl. Pour une récupération ponctuelle, retrouvez le crawl par son rid dans le tableau de bord du stockage. Pour tout ce qui est récurrent, construisez un troisième petit Zap :

Le stockage peut aussi être interrogé par url plutôt que par rid, ce qui renvoie la version la plus récemment enregistrée de cette page. Une limite à prendre en compte dès la conception : les pages stockées sont conservées 14 jours par défaut. Cloud Storage est un tampon de récupération, pas votre archive : tout ce dont vous avez besoin sur le long terme doit être copié dans votre propre système par le Receiver.

Considérations pour la production

Le pipeline ci-dessus est une preuve de concept fonctionnelle. Quelques ajouts en font quelque chose que vous pouvez laisser tourner.

Rendez le Receiver idempotent. Traitez le rid comme une clé unique et vérifiez si vous l'avez déjà traité avant d'écrire. Des tentatives de livraison, une exécution rejouée manuellement ou un Zap modifié en pleine course peuvent tous faire passer le même callback deux fois, et une ligne en double est bien plus facile à éviter qu'à nettoyer.

Validez avant d'écrire. Filtrez sur cb_status, et traitez tout le reste comme une exception avec un endroit où aller, que ce soit une feuille séparée, une alerte Slack ou une liste de reprise. Les échecs silencieux dans une automatisation sont pires que les bruyants, parce que personne ne regarde tant que les données ne sont pas déjà fausses.

Gardez le Dispatcher non bloquant. Il soumet et enregistre. Chaque fois que quelqu'un ajoute « juste une petite étape » qui lit le corps, le timeout revient.

Protégez le token. Il vit dans la configuration du Zap, pas dans des captures d'écran ni des modèles partagés. Faites-le tourner s'il fuit.

Utilisez le token le moins cher qui fonctionne. Le Normal token est plus rapide et coûte moins que le JavaScript token. Faites passer une cible au JS token quand la réponse Normal revient vide ou bloquée par un challenge, pas par précaution.

Respectez la cible. Vérifiez les conditions d'utilisation, les directives robots et les limites de débit, et tenez-vous-y. Qu'une automatisation soit facile à construire ne change rien à ce que vous avez le droit de collecter.

Où ce motif s'applique

La forme envoi-puis-callback n'est pas propre au scraping. C'est ce vers quoi vous allez chaque fois qu'un workflow doit lancer quelque chose de lent sans l'attendre.

La logique métier change ; le modèle d'exécution non. Un événement métier lance un crawl asynchrone, un callback livre le résultat, et une action en aval en fait quelque chose. Si vous préférez posséder le côté réception en code plutôt que dans Zapier, la même architecture en Python est traitée dans construire un serveur de callback Flask.

Conclusion

Le problème du scraping no-code synchrone n'a jamais été la requête HTTP. C'était de lier la durée de vie d'une étape de workflow à celle d'une récupération web, deux choses qui n'ont aucune raison de s'accorder sur le temps qu'elles devraient prendre.

Les séparer supprime la dépendance. Le Dispatcher envoie async=true et une URL de callback , obtient un rid, et se termine dans le temps d'un accusé de réception. Crawlbase crawle à son propre rythme et poste la page au Receiver, qui la valide et l'achemine plus loin. Ajouter store=true fait que les exécutions qui tournent quand même mal restent récupérables par leur rid au lieu d'être perdues.

Vous obtenez au bout du compte un pipeline dont la fiabilité ne dépend plus de la vitesse à laquelle la cible la plus lente a envie d'aller.

Questions fréquentes (FAQ)

Puis-je utiliser Crawlbase avec Zapier sans écrire de code ?

Oui. Le pipeline de ce guide utilise Webhooks by Zapier pour envoyer la requête et un Catch Hook pour recevoir le résultat, avec des étapes Formatter et Filter pour le traitement. Ni Python ni backend ne sont nécessaires. Si vos cibles sont assez rapides pour que l'asynchrone soit inutile, l'application Zapier native de Crawlbase fournit Crawl URL, Scrape Structured Data et Take Screenshot comme actions prêtes à l'emploi.

Pourquoi utiliser le crawl asynchrone avec Zapier plutôt qu'une requête normale ?

Parce qu'une action Zapier a une fenêtre d'exécution finie et qu'une récupération web n'en a pas. Avec async=true , l'action émettrice se termine dès que Crawlbase accepte la tâche et renvoie un rid, si bien qu'une page lente ou lourdement rendue ne décide plus de la survie du Zap. La page terminée arrive séparément, au Receiver.

Quelle est la différence entre cb_status et original_status ?

cb_status est le verdict de Crawlbase sur le crawl, où 200 signifie succès. Il s'appelait autrefois pc_status. original_status est le statut HTTP renvoyé par le site cible. Ils sont indépendants : un site peut répondre 404 et avoir tout de même été crawlé avec succès, et une page de challenge peut répondre 200 alors que le crawl a échoué. Faites brancher votre workflow sur cb_status.

Que se passe-t-il si le callback Zapier échoue ?

Si la requête comportait store=true, la réponse a été enregistrée dans Crawlbase Cloud Storage sous son rid, donc vous pouvez la récupérer depuis le tableau de bord du stockage ou via un petit Zap de récupération plutôt que de crawler la page à nouveau. C'est la raison d'enregistrer chaque rid au moment de l'envoi. Les pages stockées sont conservées 14 jours par défaut.

Puis-je exécuter ce pipeline sur n'importe quel site ?

Oui. Le mode asynchrone fonctionne sur n'importe quel domaine, le pipeline n'est donc pas lié à un ensemble de cibles particulier. Ce qui varie, c'est ce dont chaque cible a besoin : les pages qui s'affichent côté client veulent le JavaScript token et parfois page_wait, et certains sites sont simplement plus lents que d'autres, ce qui est précisément le problème que cette architecture absorbe. Vérifiez les conditions d'utilisation, les directives robots et les limites de débit du site avant d'y pointer un Zap planifié.

NZ

Neil Zamora

Architecte senior · Crawlbase

Architecte senior chez Crawlbase, axé sur les systèmes derrière le crawling à grande échelle : rotation de proxys, résilience anti-bot et les API qui masquent cette complexité.