|
|
|
Professor Seleznov
|
Мы проверили - ни одной статьи на эту тему нет. Ни на Хабре, ни на GitHub. Albato умеет Tilda + СБИС CRM, но не Presto. CommerceML нестабилен. Кастомный сервис — единственный рабочий путь.
Клиент пришёл с простой задачей: заказы с сайта на Tilda должны автоматически попадать в СБИС Presto. Казалось бы, популярные инструменты — должно быть готовое решение. Его не оказалось.
Написали свой сервис месяц в продакшене, всё работает. Рассказываем как — с кодом, граблями и объяснением неочевидных мест в документации СБИС.
Стек: Python, FastAPI, Pydantic, httpx, cachetools.
Tilda отправляет POST → FastAPI принимает и сразу возвращает 200 → заказ обрабатывается в фоне → уходит в СБИС Presto
Почему не готовые решения
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 на выходе. Это даёт валидацию и явные типы без лишнего кода.
Соответствие полей:
| Tilda |
СБИС |
| name, phone |
customer.name, customer.phone |
| comment |
comment |
| delivery == "Самовывоз" |
isPickup: true |
| address + address_house |
addressJSON.Address |
| items[].name/sku/price/qty |
nomenclature[].name/nomNumber/cost/count |
Маппинг оплаты — СБИС принимает строки, не числовые коды:
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/_.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-разработчик-Источник
|
|
|
|
