Если у проката уже есть сайт, мобильное приложение или договорённость с агрегатором, данные должны ходить сами. API отдаёт каталог и доступность, принимает клиентов и брони и сообщает о событиях — без выгрузок вручную и без «пришлите нам таблицу раз в неделю».
Каталог с ценами и описаниями, доступность позиций, справочники. Ответ о доступности всегда сообщает, В КАКОМ РЕЖИМЕ он посчитан: «свободно сейчас» и «свободно в интервале» — разные ответы, и интегратор обязан знать, какой получил.
Эта честность не формальность. Приложение, принявшее «свободно сейчас» за «свободно в субботу», продаст бронь, которую прокат не сможет выполнить.
Клиенты, брони и заявки. Записывающие вызовы защищены ключом идемпотентности: повтор запроса из-за обрыва связи не создаёт вторую бронь. Для интеграции это принципиально — сеть рвётся именно в тот момент, когда клиент нажал «забронировать».
Вместо опроса «а не появилось ли новое» система сама сообщает вашей стороне о событиях. Доставка подписана, чтобы получатель мог убедиться в источнике, и повторяется при недоступности адреса.
Принимающая сторона обязана быть идемпотентной: повтор доставки — нормальная часть жизни, а не сбой.
Ключи создаются и отзываются в разделе интеграций — платформа их не раздаёт и не хранит в открытом виде. Каждый ключ принадлежит вашей организации и видит только её данные.
Есть спецификация и портал разработчика: то, что обычно приходится выпрашивать письмами, лежит по адресу и открыто читается.
Нет OAuth и готовых SDK. Это сознательное решение, а не «пока не успели»: и то и другое имеет смысл, когда интеграций сотни и их пишут посторонние. Сейчас интеграции пишут для себя — ключ и спецификация решают задачу без лишнего слоя, который надо поддерживать годами.
Если вам нужен именно OAuth — скажите об этом до начала работ. Честный ответ «нет» лучше, чем обнаруженное на середине интеграции отсутствие.
Частота запросов ограничена — не для того, чтобы мешать, а чтобы одна сорвавшаяся интеграция не мешала остальным. Пределы описаны в спецификации, и при их достижении ответ сообщает, сколько ждать.
Данные отдаются в разрезе вашей организации. Межорганизационных выборок нет ни при каких ключах — это устройство системы, а не настройка.
Первый — свой сайт с бронированием: он забирает каталог и доступность, создаёт клиента и бронь, а дальше сотрудник видит её в системе как обычную. Второй — мобильное приложение проката, где к тому же нужны уведомления, и здесь работают вебхуки. Третий — агрегатор или партнёр, которому нужен только каталог и цены, без записи.
Во всех трёх случаях источник данных один — та же система, что ведёт учёт. Это снимает вечную беду интеграций, когда на сайте цена одна, в программе другая, и никто не помнит, какая правильная.
Ключ выпускается на организацию, а не на человека: подрядчик работает вашим ключом и не получает доступа к аккаунту. Закончили работы — ключ отзывается в один клик, и переделывать ничего не нужно.
Выпустите ключ, откройте спецификацию и запросите каталог — это первые пять минут. Дальше проверьте доступность на нужный период и убедитесь, что режим ответа вас устраивает: именно здесь чаще всего расходятся ожидания интегратора и правила проката.
Владелец организации выпускает ключ в разделе интеграций. Отдельного согласования не требуется.
Да, спецификация и портал разработчика доступны из системы.
Через API создаются клиенты, брони и заявки. Выдача техники — действие сотрудника в системе.
Записывающие вызовы идемпотентны: повтор с тем же ключом не создаст вторую запись.