Мы проверили - ни одной статьи на эту тему нет. Ни на Хабре, ни на GitHub. Albato умеет Tilda + СБИС CRM, но не Presto. CommerceML нестабилен. Кастомный сервис — единственный рабочий путь.

Клиент пришёл с простой задачей: заказы с сайта на Tilda должны автоматически попадать в СБИС Presto. Казалось бы, популярные инструменты — должно быть готовое решение. Его не оказалось.

Написали свой сервис месяц в продакшене, всё работает. Рассказываем как — с кодом, граблями и объяснением неочевидных мест в документации СБИС.

Стек: Python, FastAPI, Pydantic, httpx, cachetools.

Почему не готовые решения

Albato — есть коннектор Tilda + СБИС, но это СБИС CRM, не Presto. Для ресторанного бизнеса не подходит.

CommerceML — встроенная интеграция Tilda + СБИС. На бумаге работает, на практике — десятки отчётов об ошибках при подключении. Сама поддержка СБИС рекомендует использовать API.

Make/Integromat — нативного модуля СБИС нет.

Итог: кастомный сервис — единственный рабочий путь для связки Tilda → СБИС Presto.

Как Tilda отправляет данные

При отправке формы Tilda делает POST на указанный URL. По умолчанию — application/x-www-form-urlencoded, но в настройках есть чекбокс «Отправлять данные в виде application/json». Мы включили его, плюс «Передавать данные по товарам в заказе — массивом» — это важно, иначе состав заказа приходит одной строкой и его придётся парсить регуляркой.

Мы поддержали оба формата в коде — на случай если настройки изменятся:

content_type = request.headers.get("content-type", "")

if "application/json" in content_type:
    try:
        body = json.loads(raw_body)
        if isinstance(body, dict):
            data = {k.strip().lower(): v for k, v in body.items()}
        else:
            data = {}
    except json.JSONDecodeError:
        data = {}
else:
    # request.form() парсится фреймворком — менее хрупко чем json.loads(),
    # плюс Tilda всегда шлёт корректный формат
    form = await request.form()
    data = {k.strip().lower(): v for k, v in form.items()}

Тестовый запрос. При подключении webhook Tilda шлёт POST с телом test=test и ждёт 200 OK за 5–7 секунд. Если не ответили — webhook не активируется. Фильтруем первым делом:

if data.get("test") == "test": return PlainTextResponse("ok")

Retry от Tilda. Если webhook не получил 200, Tilda повторит запрос ещё 2 раза с интервалом в 1 минуту. Именно из-за этого синхронная обработка — плохая идея. Подробнее ниже.

Что ожидает СБИС

Авторизация. СБИС использует собственную схему — это не стандартный OAuth 2.0. POST-запрос на https://online.sbis.ru/oauth/service/ с тремя параметрами:

{ "app_client_id": "...", # цифровой ID приложения "app_secret": "...", # защищённый ключ "secret_key": "..." # сервисный ключ }

Из ответа берём access_token. Токен передаётся через заголовок X-SBISAccessToken — не через стандартный Authorization: Bearer.

Кешируем через TTLCache с TTL чуть меньше реального срока жизни токена. При 401 — инвалидируем кеш и повторяем один раз:

@retry_on_401
async def _send_to_saby_api(payload: SbisOrderCreate) -> None:
    """Получает токен и отправляет запрос в СБИС. retry_on_401 перехватит 401 и повторит."""
    token = await saby_auth.get_token()
    dumped = payload.model_dump(exclude_none=True)
    logger.debug("Saby payload: %s", json.dumps(dumped, ensure_ascii=False, indent=2))
    logger.debug("Saby full payload: %s", json.dumps(dumped, ensure_ascii=False))
    async with httpx.AsyncClient(timeout=settings.SABY_HTTP_TIMEOUT) as client:
        response = await client.post(
            settings.SABY_API_URL,
            json=dumped,
            headers={"X-SBISAccessToken": token},
        )
        if response.status_code >= 500:
            logger.error("Saby error response: %s", response.text)
        response.raise_for_status()

Важно про домены.

• online.sbis.ru/oauth/service/ — авторизация

• api.sbis.ru/retail/order/create — создание заказа

• api.sbis.ru/retail/v2/nomenclature/list — загрузка номенклатуры

Мы вынесли первые два в env-переменные (SABY_OAUTH_URL и SABY_API_URL), третий захардкожен в коде. Если при отладке получаете 401 или 404 — первым делом проверьте, на тот ли домен летит запрос.

Структура заказа. Эндпоинт POST https://api.sbis.ru/retail/order/create. Поле addressJSON — это строка с JSON внутри JSON-объекта. Буквально:

address_obj = {"Address": "ул. Ленина, д.5", "AptNum": "42"} payload = { "addressJSON": json.dumps(address_obj), # строка, не объект! ... }

Если передать объект вместо строки — СБИС вернёт ошибку валидации.

Архитектура сервиса

Один эндпоинт: POST /api/v1/webhook/tilda, защищённый секретным токеном в query-параметре (?token=).

Главное архитектурное решение — обрабатывать заказ асинхронно. Цепочка «авторизация СБИС + загрузка номенклатуры + создание заказа» занимает 1–3 секунды в лучшем случае. Плюс наш retry при ошибке. Синхронно мы не уложимся в таймаут Tilda, она пришлёт повторный запрос, и в СБИС появится дубль. Решение — BackgroundTasks:

@router.post("/tilda", dependencies=[Depends(verify_tilda_token)])
async def handle_webhook(request: Request, background_tasks: BackgroundTasks):
    data = await parse_body(request)
    
    if data.get("test") == "test":
        return PlainTextResponse("ok")
    
    # Tilda получает 200 немедленно, заказ обрабатывается в фоне
    background_tasks.add_task(process_order, data)
    return PlainTextResponse("ok")

Маппинг Tilda → СБИС

Используем Pydantic-модели: TildaOrder на входе, SbisOrderCreate на выходе. Это даёт валидацию и явные типы без лишнего кода.

Соответствие полей:

Маппинг оплаты — СБИС принимает строки, не числовые коды:

def _map_payment(payment: str | None) -> str:
    """Наличные → cash; Терминал / QR-код СБП / None / всё остальное → card."""
    if payment and "наличн" in payment.lower():
        return "cash"
    return "card"

Позиции без SKU пропускаются с WARNING, SKU не из прайс-листа — с ERROR. Если все позиции пропущены — бросается ValueError и заказ уходит в retry, а затем в failed_orders/. Самая частая причина: SKU в Tilda не совпадают с номенклатурой в СБИС.

Дата и время заказа. Поддерживаем два режима. Если поле time == "Ко времени" и заполнены dates и delivery_time — парсим конкретную дату и время. Иначе — now() + 5 минут. СБИС принимает формат "YYYY-MM-DD HH:MM:SS" без таймзоны и интерпретирует его как локальное время точки продаж.

Retry и fallback

Отправка в СБИС обёрнута в цикл: 4 попытки (3 retry), линейный backoff — 0, 5, 10, 15 секунд:

for attempt in range(settings.ORDER_RETRY_COUNT + 1):
    if attempt > 0:
        await asyncio.sleep(5 * attempt)
    try:
        order = TildaOrder.model_validate(form_data)
        await send_order_to_saby(order)
        return
    except Exception as e:
        last_error = e
        logger.exception(f"Попытка {attempt + 1} не удалась, tranid={tranid}: {e}")

При исчерпании всех попыток заказ сохраняется в failed_orders/<timestamp>_<tranid>.json с тремя полями: исходный payload от Tilda, текст последней ошибки и UTC-таймстамп.

Повторить вручную: POST /api/v1/failed-orders/{tranid}/retry. Эндпоинт найдёт файл по суффиксу, переименует в .retrying чтобы исключить параллельный запуск, и снова пустит через process_order.

Грабли, на которые мы наступили

addressJSON — строка, не объект. СБИС ожидает сериализованную строку JSON внутри JSON-запроса. Передашь объект — получишь ошибку валидации без внятного объяснения.

Логируйте тело ответа при 4xx, не только при 5xx. Мы логируем тело ответа СБИС только при статусе >= 500. Но валидационные ошибки — неверный SKU, кривой адрес, неправильный тип поля — СБИС возвращает как 400 или 422. Их тело в наши логи не попадает. Это наш TODO: нужно добавить logger.error(response.text) до raise_for_status(). Пока приходится смотреть тело ошибки в httpx-исключении вручную.

Если все позиции без SKU — заказ тихо уйдёт в fallback. Все 4 попытки retry упадут детерминированно с одной и той же ошибкой. Проверяйте соответствие SKU между Tilda и номенклатурой СБИС до запуска в прод.

Повторные запросы от Tilda. BackgroundTasks решает проблему полностью — сервис отвечает 200 немедленно, Tilda не делает retry. Дедупликации по tranid у нас нет; за месяц в продакшене дублей не было именно потому, что архитектура их исключает. Если у вас синхронная обработка — добавьте проверку tranid через Redis или БД.

Итог

Сервис работает стабильно. Заказы попадают в СБИС Presto автоматически в момент оформления, ручного ввода нет.

Если столкнулись с похожей задачей — пишите в комментариях, разберём. Особенно интересно услышать тех, кто работал с API Presto — там ещё есть неисследованные углы.

Автор — Алексей Громов, fullstack-разработчик