Что обязательно должно быть в API у онлайн (saas)-сервиса для продаж в 2024 году
Всем привет! Я Лаптев Алексей, основатель и главный разработчик сервисов для бизнеса в datamonster.
Проблема на рынке
Сейчас мода на датадривен и оцифровку бизнеса. Часто это сводится к необходимости построения аналитики откуда продажи и с каким успехом + автоматизация создания заявок.
И вот тут у некоторых сервисов возникает проблема что нет апи для получения этих данных.
В итоге клиент сталкивается с проблемой что текущий сервис не позволяет оцифровать бизнес, а сервис сталкивается с проблемной что клиент начинает смотреть на другие сервисы с более подходящим апи.
Что часто надо клиентам
- Автоматически создавать/обновлять заявки в нужном им сервисе
- Получать вебхуки о создании/обновлении заявок с передачей статуса, суммы, контактов клиента и client id для построения аналитики как минимум в яндекс метрике и google analytics (если заявки с сайта)
Какие должны быть вебхуки (события)
Сделка/лид/заявка создана
Обязательные данные (если они есть):
- id
- сумма
- статус
- id/email/телефон клиента
- дата
- google_client_id (_ga)
- yandex_client_id (ym_uid)
- utm-метки
Сделка/лид/заявка обновлена
Обязательные данные (если они есть):
- id
- сумма
- статус
- id/email/телефон клиента
- дата
- google_client_id (_ga)
- yandex_client_id (ym_uid)
- utm-метки
Что должно быть в API
Список сделок/лидов/заявок
Обязательные данные (если они есть):
- id
- сумма
- статус
- id/email/телефон клиента
- дата
- google_client_id (_ga)
- yandex_client_id (ym_uid)
- utm-метки
- теги
Создать сделку/лид/заявку
Обязательные данные (если они есть):
- сумма
- статус
- email/телефон клиента
- google_client_id (_ga)
- yandex_client_id (ym_uid)
- utm-метки
- теги
Обновить сделку/лид/заявку
Обязательные данные (если они есть):
- сумма
- статус
Создать примечание к сделке/лиду/заявке
Обязательные данные:
- id сделки/лида/заявки
- текст примечания
Рекомендации к реализации
Берите пример с ozon/amocrm.
Вебхуки
Хорошо
- Должна быть возможность выбрать нужное событие и указать ссылку для вебхука
- Должна быть возможность создавать множество вебхуков, ну хотя бы 10, чтобы можно было подключать разные сервисы.
- Должен быть лог исходящих вебхуков чтобы можно было понять — от вас вебхук не ушел или принимающий сервис не принял. Лог избавит от 100500 вопросов в поддержку.
Плохо
- Ставить вебхуки через API
- Ограничивать число настроенных вебхуков буквально 1-2 слотами.
API
Хорошо
- Доступ к API по токену, который можно получить в личном кабинете.
- В качестве id сущностей использовать числа, а не uuid хеш.
- Формат данных — json
- Открытый доступ к документации, которую легко найти с лендинга или нагуглить. Сама документация в каком нибуть популярном формате — swagger или аналоги.
Плохо
- Давать доступ к API через приложение с 10ю кругами ада модерации или запрос в поддержку.
- Скрывать документацию к API за личным кабинетом или выдавать только по запросу к менеджеру.
Виджеты для сайтов
Если ваш сервис рисует какие-то виджеты на сайте — не делайте их через iframe.
У любого клиента одна из важных задач — понять источник заявок, а iframe ломает всю аналитику и делает задачу нерешаемой.
Такая проблема у getcourse и yclients.
Итого
Делайте так API 3 раза в день и у клиентов голова от вашего сервиса болеть не будет, а также желания его сменить при автоматизации и аналитике их бизнеса.