HubSpot + Zapier: когда автоматизация через Zap ломает данные

Zapier — популярный способ «быстро подключить» HubSpot к другому сервису без разработчика. Создать Zap занимает минуты. Проблемы начинаются позже: при росте объёма транзакций, при ошибках в середине Zap, при дублировании событий, при rate limits. Разбираем конкретные сценарии, где HubSpot + Zapier создаёт data quality проблемы.

Почему Zapier кажется хорошим решением

Zapier даёт: быстрый старт без разработчика, 5000+ готовых коннекторов, визуальный редактор Zap. Для простых односторонних сценариев — например, «новая строка в Google Sheets -> создать контакт в HubSpot» — это работает. Проблемы появляются когда сценарий становится сложнее.

Проблема 1: Rate limits и потеря данных

HubSpot API имеет rate limits: 150 запросов в секунду (Enterprise), 100/сек (Pro). Это звучит много, пока у вас нет нескольких Zap, которые одновременно вызывают API.

Типичный сценарий: CRM + email platform + analytics tool — три Zap в HubSpot API. При пиковой нагрузке (импорт, bulk action) Zapier получает 429 Too Many Requests. Zapier имеет retry-логику, но ограниченную: 3 попытки с задержкой. Если все три провалились — данные теряются. Zapier отметит Zap как «Error» в истории, но автоматически не восстановит потерянные записи.

Результат: контакты созданы в email-платформе, но не в HubSpot. Или наоборот.

Проблема 2: Нет идемпотентности

При отправке данных через Zapier нет гарантии что один event = одна операция. Zapier может повторно отправить event если webhook не ответил вовремя. HubSpot API для большинства операций — не идемпотентен: повторный POST /contacts с тем же email создаёт дубль (если не использовать upsert endpoint явно).

# Неправильно - через Zapier POST /contacts каждый раз
{
  "properties": {
    "email": "client@example.com",
    "firstname": "John"
  }
}
# При повторном вызове: дубль контакта

# Правильно - через кастомный код: upsert по email
# POST /crm/v3/objects/contacts/upsert
{
  "properties": {"email": "client@example.com", "firstname": "John"},
  "idProperty": "email"
}

Zapier не предоставляет контроль над этим на уровне HTTP-запроса. Вы настраиваете «Action» в UI, но не управляете тем, upsert это или create.

Проблема 3: Нет транзакционности

Сложный Zap: Deal Won -> создать Invoice в FreshBooks -> обновить контакт в HubSpot -> отправить данные в Amplitude. Если шаг 2 (FreshBooks) упал — HubSpot уже обновлён, данные в Amplitude не отправлены. Транзакция «половину выполнена».

Zapier не предоставляет rollback или transaction semantics. При ошибке на шаге N — шаги 1..N-1 уже выполнены, шаги N+1..M не выполнены. Восстановление вручную.

Нативная интеграция или кастомный код решает это через:
— Атомарные операции (все или ничего)
— Dead Letter Queue для неудавшихся событий
— Idempotency keys для повторных попыток без дублей

Проблема 4: Цена при масштабе

Zapier Professional: $49/мес за 2000 задач. При 100 клиентах в месяц, Zap с 5 шагами = 500 задач только на этот поток. Добавьте другие Zap — быстро выходите за лимит.

Кастомная интеграция (Python + cloud function): ~$20–50/мес при любом объёме в разумных пределах. Разработка: разовая инвестиция.

Проблема 5: Трудная отладка

Когда данные не синхронизировались — выяснить почему в Zapier сложно. История задач показывает статус, но:
— Нет полного лога HTTP-запросов/ответов
— Нет alert при silent errors (Zapier не всегда явно сигнализирует)
— Нет метрик: сколько задач упало за месяц

Кастомная интеграция с логированием в любой системе (Datadog, CloudWatch, просто файл) даёт полную видимость.

Когда Zapier всё же оправдан

Zapier работает хорошо для:
— Прототипирования интеграции перед разработкой кастомного решения
— Низкочастотных событий (1-10 в день) без критических требований к надёжности
— Односторонних потоков без сложной бизнес-логики
— Команд без разработчика, которым нужно что-то сейчас

Правильная архитектура для HubSpot-интеграций

Если критична надёжность данных — кастомная интеграция через HubSpot API:

import requests
import time

HUBSPOT_TOKEN = "your_private_app_token"
BASE_URL = "https://api.hubapi.com"

def upsert_contact(email: str, properties: dict, max_retries: int = 3) -> dict:
    # Идемпотентный upsert - не создаёт дублей
    for attempt in range(max_retries):
        try:
            resp = requests.post(
                f"{BASE_URL}/crm/v3/objects/contacts/upsert",
                headers={"Authorization": f"Bearer {HUBSPOT_TOKEN}"},
                json={
                    "properties": {"email": email, **properties},
                    "idProperty": "email",
                },
                timeout=10,
            )
            if resp.status_code == 429:
                retry_after = int(resp.headers.get("Retry-After", 10))
                time.sleep(retry_after)
                continue
            resp.raise_for_status()
            return resp.json()
        except requests.RequestException as e:
            if attempt == max_retries - 1:
                raise
            time.sleep(2 ** attempt)
    raise RuntimeError("Max retries exceeded")

def process_deal_won(deal_id: str, contact_email: str, invoice_amount: float):
    # Атомарная последовательность с обработкой ошибок
    contact = upsert_contact(contact_email, {
        "customer": "true",
        "hs_lead_status": "CUSTOMER",
    })

    # Если следующий шаг упадёт - контакт уже обновлён (это OK, идемпотентно)
    # Логируем что нужно повторить только оставшееся
    update_deal_properties(deal_id, {"invoice_sent": "true"})

Ключевые отличия от Zapier:
— Idempotency через upsert endpoints
— Retry с exponential backoff
— Rate limit handling с Retry-After header
— Полный контроль над последовательностью шагов

Сравнение: Zapier vs кастомная интеграция

Реальный кейс

B2B SaaS (UK, HubSpot + FreshBooks + Customer.io через Zapier):

• Симптом: раз в неделю клиент не получал onboarding email. Менеджеры не понимали почему — в HubSpot сделка закрыта, email в Customer.io отправлен… нет. Zapier history: «Task Error» — FreshBooks вернул 500, Zap остановился, данные в Customer.io не дошли.
• Объём: 60 сделок в месяц × 4 шага = 240 задач. Казалось бы, немного. Но 2-3 ошибки в месяц × потерянный onboarding = реальные деньги.
• Решение: кастомная интеграция на Python + AWS Lambda. Deal Won -> Lambda -> FreshBooks (с retry) -> HubSpot upsert -> Customer.io identify. При ошибке FreshBooks — event в SQS DLQ, повтор через 5 минут. Потеря данных: 0 за 8 месяцев.

Для кого актуально

• HubSpot-команды с 50+ сделками в месяц и несколькими интеграциями через Zapier
• Команды где потеря события = потеря денег (onboarding, биллинг, analytics)
• SaaS с многошаговыми интеграциями: CRM -> billing -> analytics -> email -> уведомления
• Компании где нашли дубли контактов или пропущенные события — вероятно, Zapier-related

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

Zapier Professional имеет «Premium support» — это не решает надёжность?

Поддержка помогает разобраться с настройкой Zap. Не решает архитектурные проблемы: rate limits, отсутствие idempotency, нет транзакционности. Эти ограничения — в природе продукта.

Make (Integromat) — лучше Zapier для HubSpot?

Make имеет более гибкий роутинг и обработку ошибок. Но фундаментальные проблемы те же: нет транзакционности, ограниченная idempotency, стоимость при масштабе. Для сложных интеграций — аналогичный вывод.

Как HubSpot Operations Hub соотносится с Zapier?

HubSpot Operations Hub предоставляет Custom Code Actions — выполнение JavaScript прямо в HubSpot workflow. Это мощнее Zapier для HubSpot-to-HubSpot логики, но не решает надёжную интеграцию с внешними системами.

Сколько стоит кастомная интеграция вместо Zapier?

Разработка: зависит от сложности, обычно 20–80 часов. Эксплуатация: AWS Lambda или аналог при 100k invocations/мес — меньше $1. При объёме от 3000 задач/мес Zapier Team ($299) vs cloud function ($10–30) — разница очевидна уже за 6 месяцев.

Итого

• Zapier подходит для прототипов и низкочастотных несложных потоков
• При объёме 50+ events/день с несколькими шагами — риски rate limits и потери данных
• Нет idempotency по умолчанию: риск дублей при retry
• Нет транзакционности: при ошибке на шаге N — половина данных записана, половина нет
• Кастомная интеграция с upsert, retry и dead letter queue — надёжнее и дешевле при объёме

Если у вас HubSpot + Zapier и вы периодически находите пропущенные данные или дубли — опишите архитектуру Zap. Exceltic.dev проведёт аудит и предложит надёжную замену.