Как собрать конвейер веб-скрапинга на ZapierОтправить задание, поймать обратный вызов и перестать ждать медленные страницы

Zap, который скрапит страницу, обычно работает с первого раза, а ломаться начинает позже. Схема знакомая: действие Webhooks by Zapier вызывает эндпоинт скрапинга, ждёт HTML и передаёт его в строку Google Sheets. В редакторе всё проходит на быстрой тестовой странице. Затем оно встречает настоящую цель, которая отрисовывается через JavaScript, стоит за проверкой или просто отвечает медленно, и действие упирается в свой лимит времени.

Первый порыв - обвинить запрос. С запросом всё в порядке. Проблема в том, что одно действие Zapier удерживает открытыми две операции с очень разным временем жизни: шаг рабочего процесса, измеряемый секундами, и получение страницы, которое может занять намного больше, когда цель так решит.

Решение в том, чтобы перестать заставлять одно ждать другое. Zapier отправляет задание на краулинг и завершается. Crawlbase выполняет краулинг и сообщает результат, когда он появится. Это руководство собирает такой конвейер: два Zap, без кода, и путь восстановления для запусков, которые пошли не так.

Почему синхронный скрапинг перестаёт работать

У действия Zapier есть конечное окно выполнения. Для платформы автоматизации это разумное решение: шаги должны быть короткими, и платформа, выполняющая миллионы таких шагов, не может позволить ни одному из них занимать слот бесконечно.

Получение веб-страницы этого ожидания не соблюдает. Время загрузки задаёт цель, а не вы. Страница товара может ответить за 400 миллисекунд в два часа ночи и занять двадцать секунд во время распродажи. Список, насыщенный JavaScript, нужно сначала отрисовать, прежде чем появится что-то, что стоит вернуть. Сайт под нагрузкой или решивший показать проверку способен растянуть загрузку далеко за пределы того, на что рассчитывал шаг рабочего процесса.

В результате получается рабочий процесс не столько сломанный, сколько непредсказуемый. Он справляется с быстрыми страницами и отваливается по таймауту на медленных, то есть отказывает ровно на тех целях, ради которых автоматизацию и затевали.

Повторные попытки не помогают, потому что повтор воспроизводит ту же связку с той же целью. Не помогает и разбиение списка URL на меньшие партии, поскольку сбой происходит на уровне запроса, а не объёма. Измениться должна форма рабочего процесса: с запрос, ожидание, обработка на отправка, краулинг, обратный вызов, обработка.

Асинхронная архитектура

Crawlbase Crawling API поддерживает такое разделение напрямую. В синхронном режиме по умолчанию HTTP-запрос остаётся открытым, пока страница не готова, и тело возвращается тем же ответом. С async=true API вместо этого принимает задание, сразу возвращает идентификатор запроса (rid) и выполняет краулинг в фоне. Добавив callback=<webhook URL> , вы указываете, куда отправить готовую страницу методом POST.

Здесь важно различие между запрос принят и краулинг завершён. Диспетчер узнаёт только первое. Сама страница приходит на другой Zap, в момент, который никто не планировал, и именно поэтому конвейер перестаёт зависеть от того, насколько медленная цель.

Две детали легко упустить. Параметр называется callback, а не callback_url. И для всего, что вы собираетесь запускать в продакшене, соедините его с store=true, который сохраняет ответ в Crawlbase Cloud Storage под тем же rid. Один этот флаг определяет, будет ли потерянный обратный вызов стоить вам одного обращения к хранилищу или ещё одного краулинга.

Если ваши цели быстрые и простые, ничего этого может не понадобиться. Штатная интеграция Crawlbase с Zapier даёт вам Crawl URL, Scrape Structured Dataи Take Screenshot как обычные действия Zap, вообще без возни с вебхуками. К схеме с обратным вызовом стоит переходить тогда, когда именно время загрузки ломает ваш рабочий процесс.

Соберите приёмник раньше диспетчера

У этих двух Zap есть зависимость по порядку сборки, на которой многие спотыкаются. Catch Hook Приёмника генерирует URL, который Диспетчер обязан передать как callback, поэтому Приёмник должен существовать первым. Если начать с Диспетчера, у вас будет запрос на краулинг и некуда девать результат.

Прежде чем начать, вам понадобится:

1. Учётная запись Crawlbase. Зарегистрируйтесь и скопируйте токен Crawling API из панели управления. Обычный токен покрывает большинство страниц; токен JavaScript нужен для целей, которым требуется отрисовка.
2. Учётная запись Zapier на тарифе, где разрешены многошаговые Zap, поскольку оба Zap здесь многошаговые.
3. Назначение для данных: таблица Google Sheets, канал Slack, база Airtable или CRM.
4. Тестовый URL. Возьмите реальную страницу из того рабочего процесса, который вы автоматизируете, а не заглушку, чтобы увиденное время совпало с тем, которое вы получите.

Zap B: приёмник

Приёмник - это эндпоинт обратного вызова. Он никогда не запускает краулинг. Он ждёт, когда Crawlbase отправит готовую страницу, затем проверяет её и направляет дальше.

Шаг 1: создать Catch Hook

В Zapier создайте новый Zap и выберите Webhooks by Zapier как триггер, с событием Catch Hook. Zapier сгенерирует Custom Webhook URL , который выглядит так:

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

Скопируйте его. Это значение параметра Crawlbase callback в Диспетчере, и это единственное, что связывает две половины конвейера.

Шаг 2: дать ему образец полезной нагрузки

Zapier должен увидеть хотя бы один запрос, прежде чем сможет предложить поля обратного вызова для сопоставления. Можно воспользоваться его собственными средствами тестирования или отправить образец самостоятельно. Настоящий обратный вызов Crawlbase несёт полученное содержимое вместе с метаданными, включая rid, url, original_status и cb_status.

Сопоставлять поля по реальному обратному вызову, а не по выдуманному образцу, стоит потраченной минуты. Имена полей в написанной вручную тестовой нагрузке имеют свойство не совпадать с тем, что приходит на самом деле.

Шаг 3: добавить действия обработки

Когда поля доступны, добавьте всё, что должно проверять, преобразовывать и сохранять результат. Formatter by Zapier выполняет обрезку, извлечение подстрок и разделение без кода. Действие Google Sheets: Create Spreadsheet Row может сопоставляться так:

Google Sheets проще всего проверять, но назначение взаимозаменяемо: Slack, Salesforce, Airtable, Notion или что угодно ещё, с чем соединяется Zapier. Ни одно из этих действий не выполняется, пока Диспетчер открыт, потому что Диспетчер завершился задолго до прихода обратного вызова.

Шаг 4: включить приёмник

Опубликуйте Приёмник прежде, чем отправите хотя бы один настоящий асинхронный запрос. Catch Hook, принадлежащий выключенному Zap, не обработает то, что ему прислали, а обратный вызов, пришедший на отключённый эндпоинт, - это краулинг, за который вы заплатили и который выбросили. Включить Приёмник первым - самая дешёвая привычка во всей этой сборке.

Zap A: диспетчер

Диспетчер берёт URL из существующего рабочего процесса, отправляет его на асинхронный краулинг, записывает ridи завершается. В этом вся его работа.

Шаг 1: выбрать триггер

Триггер - это то, что порождает URL в вашем деле:

• Schedule by Zapier для регулярных проверок цены или наличия
• Google Sheets: New Spreadsheet Row чтобы обойти URL, как только он добавлен в таблицу
• Google Forms: New Response чтобы обойти URL, который кто-то отправил

Сопоставьте поле с полным URL, включая схему.

Шаг 2: добавить запрос к Crawlbase

Добавьте Webhooks by Zapier как действие, с событием GET, и укажите URL запроса https://api.crawlbase.com/. GET соответствует тому, как Crawling API документирует свои параметры. POST тоже работает, если параметры доходят до эндпоинта в целости.

Шаг 3: настроить параметры

В разделе Query String Paramsдобавьте пять записей:

Два момента, за которыми стоит следить. Значение url должно быть закодировано для URL, что особенно важно, когда целевой URL несёт собственную строку запроса. А токен принадлежит конфигурации Zap и больше нигде: держите его вне скриншотов, общих шаблонов Zap и переписки с поддержкой, и меняйте его, если он всё же утёк.

Для целей, которым нужна отрисовка, используйте токен JavaScript и добавьте параметры отрисовки, такие как page_wait, описанные в Crawling API. Стоит рассмотреть и format=json : он возвращает статус, URL и тело одной оболочкой JSON, что обычно упрощает сопоставление полей в Приёмнике.

Эквивалентный запрос, если вы хотите сначала проверить настройку вне 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'

Выполнить его вручную - хороший способ отделить проблему Crawlbase от проблемы Zapier до того, как обе окажутся связаны.

Шаг 4: записать идентификатор запроса

Добавьте ещё одно действие, которое запишет rid куда-то надолго, вместе с исходным URL и меткой времени отправки. Строки в таблице достаточно.

Это не учёт ради учёта. rid - это ключ связи между всеми тремя местами, где существует краулинг: отправка, будущий обратный вызов и сохранённая копия. Именно он позволяет ответить, обходили ли URL раньше, обрабатывался ли уже этот обратный вызов и куда делся недостающий результат.

Шаг 5: включить диспетчер

Опубликуйте его и удержитесь от соблазна добавить ещё один шаг. Любое действие, пытающееся прочитать тело страницы из ответа Диспетчера, возвращает то самое ожидание, которое вы только что убрали, а вместе с ним и таймаут. Ответ Диспетчера содержит rid. Страница принадлежит Приёмнику.

Чтение обратного вызова: cb_status и original_status

Когда краулинг завершён, Crawlbase отправляет результат на Catch Hook. Используйте Test trigger после настоящего краулинга или откройте недавний запуск Zap и сопоставляйте по тому, что действительно пришло. Важные поля:

• Полученное содержимое, в виде HTML или разобранного JSON, если вы запросили скрапер
• cb_status, вердикт Crawlbase по краулингу. 200 означает успех. Раньше он назывался pc_status.
• rid, связывает этот обратный вызов с отправкой
• original_status, HTTP-статус, который вернул целевой сайт
• url, страница, которую обходили

Эти два поля статуса отвечают на разные вопросы, и их смешение - самый частый источник плохих данных в подобном конвейере. original_status описывает, что сказал сайт. cb_status описывает, получил ли Crawlbase ответ успешно.

Поэтому поставьте шаг Filter by Zapier перед действием назначения и продолжайте только тогда, когда cb_status равен 200. Всё, что идёт дальше, увидит только те страницы, которые действительно были получены.

Держите разбор и передачу раздельно, где это возможно. Formatter by Zapier покрывает обычную работу с текстом, а Code by Zapier нужен, когда извлечение действительно нестандартное. Для сайтов, которые Crawlbase уже разбирает, параметр scraper возвращает структурированный JSON и полностью убирает шаг разбора.

Проверьте весь поток один раз

Прогоните один URL от начала до конца, прежде чем включать объём:

1. Убедитесь, что Приёмник в положении On и что URL его Catch Hook - это именно то, что Диспетчер отправляет как callback.
2. Переведите Диспетчер в положение On.
3. Запустите триггер: добавьте тестовую строку, выполните расписание, отправьте форму.
4. Посмотрите историю Диспетчера. Действие Webhooks должно завершиться быстро и вернуть rid, а не страницу.
5. Дайте краулингу время завершиться.
6. Проверьте историю Приёмника на запуск по обратному вызову.
7. Проверьте в назначении строку, сообщение или запись.

Если Диспетчер отработал, а Приёмник ни разу не запустился, обычных причин три: URL в callback неверен или содержит опечатку, Приёмник был выключен, когда Crawlbase пытался доставить результат, или шаг Filter отбросил запуск до того, как он дошёл до действия назначения. Проверяйте в этом порядке.

Cloud Storage как путь восстановления

Обратные вызовы - обычный путь доставки. Продакшен-системам нужен ответ на случай, когда обычное не случается: Приёмник правили, приложение-назначение лежало, ошибочный фильтр отбросил хороший результат.

Именно это и даёт store=true . Ответ сохраняется в Crawlbase Cloud Storage под rid, так что потерянный обратный вызов превращается в обращение к хранилищу, а не в повторный краулинг. Для разовых случаев найдите краулинг по rid в панели хранилища. Для всего повторяющегося соберите третий небольшой Zap:

Хранилище можно запрашивать и по url , а не по rid, тогда вернётся последняя сохранённая версия этой страницы. Ограничение, которое стоит заложить в проект: сохранённые страницы хранятся 14 дней по умолчанию. Cloud Storage - это буфер восстановления, а не ваш архив, поэтому всё, что нужно надолго, Приёмник должен копировать в вашу собственную систему.

Что учесть в продакшене

Конвейер выше - работающее подтверждение концепции. Несколько дополнений превращают его в то, что можно оставить работать.

Сделайте Приёмник идемпотентным. Считайте rid уникальным ключом и проверяйте перед записью, обрабатывали ли вы его раньше. Повторные доставки, вручную перезапущенный прогон или Zap, отредактированный на ходу, - всё это может провести один и тот же обратный вызов дважды, а дублирующую строку намного проще предотвратить, чем вычищать.

Проверяйте перед записью. Фильтруйте по cb_statusи относитесь ко всему остальному как к исключению, у которого есть куда пойти: отдельная таблица, оповещение в Slack или список повторов. Тихие сбои в автоматизации хуже громких, потому что никто не смотрит, пока данные уже не испорчены.

Держите Диспетчер неблокирующим. Он отправляет и записывает. Каждый раз, когда кто-то добавляет "всего один маленький шаг", читающий тело, таймаут возвращается.

Берегите токен. Он живёт в конфигурации Zap, а не в скриншотах и общих шаблонах. Смените его, если он утёк.

Берите самый дешёвый токен, который справляется. Обычный токен быстрее и стоит меньше, чем токен JavaScript. Переводите цель на токен JavaScript тогда, когда обычный ответ приходит пустым или заблокированным проверкой, а не на всякий случай.

Уважайте цель. Проверьте условия использования, директивы robots и лимиты частоты и соблюдайте их. То, что автоматизацию легко собрать, не меняет того, что вам разрешено собирать.

Где эта схема уместна

Форма "отправил и получил обратный вызов" не специфична для скрапинга. К ней прибегают всегда, когда рабочий процесс должен запустить что-то медленное, не дожидаясь результата.

Бизнес-логика меняется; модель выполнения - нет. Бизнес-событие запускает асинхронный краулинг, обратный вызов доставляет результат, а последующее действие что-то с ним делает. Если принимающую сторону вы предпочитаете держать в коде, а не в Zapier, та же архитектура на Python разобрана в материале как собрать сервер обратных вызовов на Flask.

Заключение

Проблема синхронного скрапинга без кода никогда не была в HTTP-запросе. Она была в привязке времени жизни шага рабочего процесса ко времени жизни загрузки страницы - двух вещей, у которых нет причин сходиться в том, сколько им положено длиться.

Их разделение снимает эту зависимость. Диспетчер отправляет async=true и URL callback , получает ridи завершается за время подтверждения. Crawlbase выполняет краулинг по своему расписанию и отправляет страницу Приёмнику, который её проверяет и направляет дальше. Добавленный store=true означает, что запуски, которые всё же пошли не так, восстанавливаются по rid , а не теряются.

В итоге получается конвейер, надёжность которого больше не зависит от того, насколько быстрой согласна быть самая медленная цель.

Часто задаваемые вопросы

Можно ли использовать Crawlbase с Zapier без написания кода?

Да. Конвейер из этого руководства использует Webhooks by Zapier для отправки запроса и Catch Hook для получения результата, а также шаги Formatter и Filter для обработки. Ни Python, ни бэкенд не нужны. Если ваши цели достаточно быстрые и асинхронный режим вам вовсе не нужен, штатное приложение Crawlbase для Zapier даёт Crawl URL, Scrape Structured Data и Take Screenshot как готовые действия.

Зачем использовать асинхронный краулинг с Zapier вместо обычного запроса?

Потому что у действия Zapier есть конечное окно выполнения, а у загрузки веб-страницы его нет. С async=true отправляющее действие завершается, как только Crawlbase принимает задание и возвращает rid, поэтому медленная или тяжело отрисовываемая страница больше не решает, выживет ли Zap. Готовая страница приходит отдельно, в Приёмник.

Чем отличаются cb_status и original_status?

cb_status - это вердикт Crawlbase по краулингу, где 200 означает успех. Раньше он назывался pc_status. original_status - это HTTP-статус, который вернул целевой сайт. Они независимы: сайт может ответить 404 и всё равно быть успешно обойденным, а страница проверки может ответить 200 , тогда как сам краулинг не удался. Ветвите рабочий процесс по cb_status.

Что произойдёт, если обратный вызов Zapier не сработает?

Если запрос содержал store=true, ответ был сохранён в Crawlbase Cloud Storage под своим rid, поэтому вы можете получить его из панели хранилища или через небольшой восстановительный Zap, а не обходить страницу заново. Именно поэтому каждый rid записывают в момент отправки. Сохранённые страницы хранятся 14 дней по умолчанию.

Можно ли запускать этот конвейер на любом сайте?

Да. Асинхронный режим работает на любом домене, поэтому конвейер не привязан к какому-то определённому набору целей. Различается то, что нужно каждой цели: страницы, которые отрисовываются на стороне клиента, требуют токен JavaScript и иногда page_wait, а некоторые сайты просто медленнее других, и это именно та проблема, которую данная архитектура и гасит. Проверьте условия использования сайта, директивы robots и лимиты частоты, прежде чем направлять на него запланированный Zap.

NZ

Neil Zamora

Старший архитектор · Crawlbase

Старший архитектор в Crawlbase, сосредоточен на системах, стоящих за краулингом в больших масштабах: ротация прокси, устойчивость к anti-bot и API, скрывающие эту сложность.