Интеграция по API: что это и что выяснить заказчику сайта

Коротко: интеграция по API в этой статье - обращение сайта к стороннему сервису (оплата, доставка, CRM) по правилам, которые сервис записал в своей документации. От владельца сайта сервису нужны личный кабинет, секретный ключ или токен и подходящие права. Ключ - секрет: ЮKassa и Битрикс24 прямо просят его не публиковать. Проверка идёт в тестовом режиме, а у каждого сервиса он устроен по-своему.

Статья для владельца бизнеса или маркетолога, который заказывает сайт или интернет-магазин и слышит от подрядчика слова интеграция по API. Она отвечает на три вопроса: что это такое, что сервис требует от владельца сайта и что спросить у подрядчика до начала работы.

Определения интеграции по API на страницах из раздела «Источники» нет. Слово API определяет глоссарий MDN, а правила взяты из документации трёх сервисов: ЮKassa (приём платежей), Битрикс24 (CRM) и Яндекс Доставки. Для Яндекс Доставки взята одна страница - о доступе к API Доставки по России; API экспресс-доставки описан в справке отдельно и здесь не рассматривается. Каждое правило названо вместе со страницей, где оно сказано. Правила одного сервиса на другие не переносятся: у других сервисов может быть иначе. Общий вывод сделан только там, где перечислены все три источника. Страницы открыты 10.10.2026, дат на страницах сервисов нет.

Кода запросов, методов и параметров здесь нет: это работа разработчика. Цен и сроков интеграций тоже нет: на страницах из раздела «Источники» их нет. Шаги подключения оплаты и выдача доступа в кабинет ЮKassa описаны в статье о подключении оплаты на сайт. Ключ для карты разобран в статье о Яндекс Карте на сайте. Автоплатежи вынесены в статью о рекуррентных платежах.

Пример вымышленный: магазин садового инвентаря example.ru. Подрядчик предлагает подключить к нему оплату, доставку и учёт клиентов в CRM.

Что такое API и что значит интеграция по API?

Коротко: MDN описывает API как набор функций и правил, по которым одна программа взаимодействует с другими программными компонентами. В веб-разработке MDN называет среди них сторонние сайты и сервисы. Интеграция по API в статье значит, что сайт обращается к сервису по этим правилам и получает ответ.

Глоссарий API - Глоссарий MDN Web Docs | MDN в русском варианте переведён сообществом. Смысл первого абзаца: API - набор функций и правил, по которым программное обеспечение, предоставляющее API, взаимодействует с другими программными компонентами. Для веб-разработки страница пишет:

«В веб-разработке API обычно представляет собой набор элементов кода (например методов, свойств, событий и URL), которые разработчик может использовать в своих приложениях для взаимодействия с (...) сторонними веб-сайтами и сервисами.»

• MDN Web Docs, API - Глоссарий MDN Web Docs | MDN, страница открыта 10.10.2026

В вашем случае своё приложение - сайт магазина, а сторонний сервис - платёжный сервис, служба доставки или CRM. У каждого сервиса есть документация для разработчиков, где записано, какие обращения он принимает. Что через API можно делать, три документации называют по-разному:

• ЮKassa: «С помощью этого API вы можете отправлять запросы на оплату, сохранять платежную информацию для повторных списаний, совершать возвраты, делать выплаты и многое другое» (Формат взаимодействия с API ЮKassa - Прием оплаты по API ЮKassa).
• Яндекс Доставка: страница о доступе заканчивается шагом «Создайте заявку и отслеживайте состояние заказа с помощью API в соответствии с порядком обработки заявки» (Как получить доступ к API | Яндекс Доставка).
• Битрикс24: среди разделов API главная страница документации называет CRM и поясняет: «Лиды, сделки, контакты, компании, смарт-процессы» (REST API Битрикс24 и приложения для Маркет).

Отсюда вывод автора статьи, он не взят из источников: интеграция по API - это обмен между сайтом и сервисом. Сайт отправляет данные, например запрос на оплату или заявку на доставку, и получает ответ или статус. Во введении MDN сторонние API описаны как API, которые «не встроены в браузер по умолчанию» (Введение в web APIs - Изучение веб-разработки | MDN).

Как выглядит обмен данными на примере одного заказа?

Коротко: порядок шагов придуман для примера, каждый шаг подписан документацией, на которую опирается. Сайт example.ru создаёт платёж, получает статус, передаёт службе доставки заявку и записывает клиента в CRM. На каждом шаге он обращается к своему сервису со своим секретом, а у каждого сервиса секрет свой и берётся из своего места.

1. Покупатель оформляет заказ, сайт создаёт платёж. Быстрый старт ЮKassa начинается шагом «Шаг 1. Создайте платеж» и называет платёж так: «Платеж - главная сущность API ЮKassa.»
2. Покупатель платит на стороне сервиса. В сценарии из быстрого старта «пользователь выбирал способы оплаты и вводил данные на стороне ЮKassa».
3. Сервис сообщает сайту о результате: уведомление приходит на адрес из настроек, сайт подтверждает получение (подробности в разделе о вебхуках).
4. Сайт передаёт заказ службе доставки. Страница Яндекс Доставки о доступе к API Доставки по России называет два действия: создать заявку и отслеживать состояние заказа (цитата в предыдущем разделе).
5. Сайт или менеджер заносит клиента в CRM. Документация Битрикс24 относит к CRM лиды, сделки, контакты и компании.

Три сервиса дают три секрета из трёх разных мест: ключ из кабинета ЮKassa, токен из кабинета Яндекс Доставки и вебхук из раздела для разработчиков в Битрикс24. Отсюда вопрос подрядчику: кто хранит все три и кто знает, где взять их заново.

Какие слова подрядчика встретятся в документации сервисов?

Коротко: слова вокруг API объяснены в документации коротко и у каждого сервиса по-своему. Слово вебхук у Битрикс24 и у ЮKassa описывает запросы в противоположных направлениях. Определения REST на страницах из раздела «Источники» нет: ЮKassa только пишет, что её API построено на REST-принципах.

У каждого слова в таблице стоит формулировка источника и его название.

Слово вебхук читается в двух смыслах. У Битрикс24 входящий вебхук - инструмент, которым вызывают методы API: запрос отправляет ваша сторона. У ЮKassa уведомление приходит само, когда меняется статус платежа: запрос отправляет сервис. Это сопоставление двух формулировок из таблицы, ни один источник его не делает, поэтому, когда подрядчик говорит вебхук, уточните, о каком направлении речь.

Чем интеграция по API отличается от виджета и готового модуля?

Коротко: ключ ЮKassa нужен и сайту, интегрированному по API, и сайту с готовым платёжным модулем, но вставляют его в разных местах: в поле настроек модуля или в код системы. Виджет - блок чужого сервиса внутри страницы, он разобран в отдельной статье. Какой способ выбран, стоит записать в задание.

Документ Секретный ключ для интеграции с ЮKassa называет тех, кому ключ нужен: «Тем, у кого сайт интегрирован с ЮKassa по API» и «Тем, кто использует платежный модуль ЮKassa». Кому он не нужен, сказано там же: «Если ваш способ подключения - HTTP-протокол или ваша CMS работает на основе старого протокола ЮKassa, секретный ключ не нужен. Способ подключения можно посмотреть в Настройках магазина».

Куда ключ прописывают, документ делит на два случая:

• Готовый модуль для CMS: «просто перейдите в настройки модуля и вставьте скопированный ключ в поле Секретный ключ».
• Самописная система: «секретный ключ нужно передавать в заголовках всех запросов по API ЮKassa», а прописать его нужно в коде системы.

Для заказчика разница в том, кто это делает и где ключ потом лежит. В поле настроек модуля ключ вводит человек с доступом в админку сайта, в коде системы его размещает разработчик. Это вывод автора из двух цитат.

У Битрикс24 способы подключения названы в разделе С чего начать | REST API Битрикс24 и приложения для Маркет: «входящий вебхук, локальное приложение или тиражное приложение». О вебхуке в разделе Как выполнить свой первый запрос к API сказано: «Входящие вебхуки подходят для личного пользования и внутренних сценариев, где запросы выполняются от имени одного пользователя». Для приложений, которые работают у разных пользователей, там назван протокол авторизации OAuth 2.0.

Виджет - блок чужого сервиса внутри вашей страницы: карта, плеер, окно чата, платёжная форма. Что проверять у такого блока, разобрано в статье о виджете на сайте. Готовые модули и плагины CMS и вопросы к ним описаны в статье о CMS, в разделе о ядре и плагинах. Если подрядчик говорит подключим по API, уточните, идёт ли речь о готовом модуле, о коде на сервере сайта или о блоке на странице. От ответа зависит, у кого будет ключ и кто его заменит.

Что сервис требует от владельца сайта?

Коротко: в трёх документациях секрет доступа выпускают из личного кабинета. У ЮKassa право выпустить ключ зависит от роли пользователя, у Битрикс24 право создавать вебхуки открывает администратор. Страница о доступе к API Доставки по России о ролях не говорит: в кабинет входят с выданными логином и паролем. ЮKassa просит идентификатор магазина и секретный ключ, Яндекс Доставка токен, Битрикс24 входящий вебхук. Вывод, что выпустить ключ может тот, кто владеет кабинетом, сделан из этих трёх источников; для других сервисов его надо проверять отдельно.

Что нужно получить и где оно лежит, три документации называют так:

ЮKassa. Разработчику без доступа документ о формате взаимодействия советует: «попросите владельца магазина добавить вас как пользователя с ролью Разработчик». Раздел Роли пользователей в личном кабинете ЮKassa сообщает, что после регистрации в кабинете есть один пользователь, Владелец, и что приглашать новых могут Владелец и Управляющий. Строка «Настройки магазина (выпуск секретного ключа, выдача доступов приложению, выбор готового решения для интеграции)» отмечена для ролей Владелец, Управляющий и Разработчик. Документ о секретном ключе добавляет: «Если у вас несколько магазинов, для каждого нужен свой ключ.»

Битрикс24. Вебхук создают в самом Битрикс24. Документация предупреждает: «Если пункта Входящий вебхук нет, значит право на создание вебхуков закрыто. Попросите администратора дать доступ к созданию вебхуков.»

О правах вебхука в разделе сказано так: «Запросы выполняются с правами пользователя, который создал вебхук, и только в рамках выбранных скоупов.» Раздел Как получить доступ к REST API называет три способа получить доступ: оформить подписку Маркетплейс, включить пробный режим или запросить NFR-ключ для разработки тиражных приложений. О подписке там сказано: «Она доступна на платных тарифах Битрикс24, стоимость зависит от тарифа.» Какие тарифы включают REST API и сколько стоит подписка, раздел не называет, поэтому в статье этого нет: уточняйте в своём Битрикс24 и у подрядчика.

Яндекс Доставка. Путь к токену описан так: «Войдите в личный кабинет с помощью выданного вам логина и пароля. Перейдите на вкладку Интеграция. В разделе Активируйте интеграцию нажмите Получить токен.» После этого токен виден в кабинете на вкладке «Профиль компании → Токен для API».

Кому принадлежит исключительное право на заказной сайт, разобрано в статье о договоре на разработку сайта. Здесь вопрос другой: кто в вашей компании владеет кабинетом сервиса. По документации ЮKassa, Яндекс Доставки и Битрикс24 от этого зависит, кто сможет выпустить ключ или токен: у ЮKassa и Битрикс24 это связано с ролью или правом, у Яндекс Доставки токен получают под логином кабинета.

Почему ключ - секрет и где его нельзя хранить?

Коротко: ЮKassa просит хранить секретный ключ в защищённом месте и не публиковать на сторонних ресурсах. Битрикс24 просит не встраивать секретный код вебхука в публичный код страниц и скриптов. В описании доступа к API Доставки по России Яндекс Доставка пишет, что токен перестаёт действовать при смене пароля кабинета. Запросы к API ЮKassa, по её документации, отправляют с сервера сайта, поэтому ключу место там же.

Документ о формате взаимодействия пишет: «Секретный ключ отвечает за безопасность ваших данных. Храните его в защищенном месте и не публикуйте на сторонних ресурсах (например, вместе с примерами кода).» Быстрый старт добавляет: «Все запросы к API ЮKassa необходимо отправлять с вашего сервера.» Ключ передают в запросах, значит он нужен тому, кто их отправляет, то есть серверу. Это вывод автора из двух источников. Что такое серверная часть сайта, объясняет статья о статическом и динамическом сайте, раздел о том, что даёт серверная часть.

Битрикс24 о вебхуке: «Никому не передавайте секретный код вебхука и не встраивайте его в публичный код веб-страниц или скриптов.» Стартовый раздел шире: «секреты вебхуков, токены и ключи приложения не попадают в публичный код и логи».

Как меняют ключ, описывает документ о секретном ключе:

• Выпуск: после «Выпустить ключ» и подтверждения паролем из смс ключ показывается в окне. Предупреждение: «Ключ доступен только в этом окне - скопируйте его, скачайте его в файле и сохраните у себя в надёжном месте. После закрытия окна мы скроем ключ, он останется только у вас.»
• Перевыпуск: «После перевыпуска текущий секретный ключ будет работать ещё 48 часов. За это время пропишите новый везде, где нужно.» Активным остаётся последний выпущенный ключ.
• Удаление: «После удаления секретный ключ перестанет работать - убедитесь, что он не используется.»

На странице о доступе к API Доставки по России срок и причина сброса записаны так: «Bearer-токен действует неограниченное время. Если вы поменяете пароль от личного кабинета, ваш Bearer-токен перестанет действовать, его нужно будет получить повторно.» Если пароль кабинета сменят, токен перестанет действовать. Стоит выяснить, кто знает этот пароль и что тогда будет с доставкой на сайте.

Права вебхука Битрикс24 равны правам создавшего его пользователя. Что станет с вебхуком, если сотрудник уйдёт, указанные разделы не описывают. Это вопрос подрядчику и администратору вашего Битрикс24.

Что такое тестовая и боевая среда?

Коротко: у ЮKassa тестовый магазин проводит платежи как настоящие, деньги не списываются; проверить в нём можно только оплату картой и кошельком ЮMoney. У API Доставки по России (Яндекс Доставка) боевой и тестовый доступ описаны отдельно, а в тестовой среде обрабатываются адреса только по Москве. Способ оплаты или город, которых тест не покрывает, в нём проверить нельзя.

У API Доставки по России (Яндекс Доставка) доступ делится на боевой и тестовый, ЮKassa называет магазины настоящим и тестовым, и у каждого сервиса это устроено по-своему.

Тестовый режим ЮKassa открыт заранее: он «доступен сразу после регистрации в личном кабинете ЮKassa» и позволяет протестировать платежи «даже до указания данных компании и заключения договора». Ключ тестового магазина выпускается автоматически, а ключ настоящего магазина «нужно сгенерировать и активировать паролем из смс». В быстром старте стоит напоминание: «Помните, что для приема реальных платежей нужно использовать идентификатор и секретный ключ настоящего магазина.» Пошаговая проверка оплаты описана в статье об оплате.

У Битрикс24 в указанных разделах тестовая среда для заказчика не описана: тестовый Битрикс24 упомянут только в связи с NFR-ключом для разработчиков тиражных приложений. Есть пробный режим подписки Маркетплейс: «В этот период REST API будет доступен для тестирования и разработки.» Для коробочной версии раздел ставит условие: пробный период можно активировать только при наличии активной лицензии.

Из таблицы видно, что тест покрывает не всё: способы оплаты и города покупателей стоит сравнить с тем, что он проверяет. Адреса по Москве тестовая среда обрабатывает. Другие города она, по документации, не обрабатывает, и как проверять доставку туда, нужно спросить у подрядчика.

Что такое вебхук и почему ему нужна серверная часть?

Коротко: в терминах ЮKassa вебхук - уведомление, которое сервис сам отправляет сайту, когда меняется статус объекта, например платежа или возврата. Для приёма нужен адрес на стороне сайта: HTTPS, порт 443 или 8443. Получение подтверждают ответом с кодом 200. Для ответа по этому адресу нужна программа на стороне сайта; слов серверная часть в документе нет.

Документ Входящие уведомления - Прием оплаты API ЮKassa объясняет назначение: уведомления «пригодятся в тех случаях, когда объект API изменяется без вашего участия». Пример оттуда: если пользователю нужно подтвердить платёж, оплата может занять «от нескольких минут до нескольких часов». Периодически опрашивать статус платежа при этом не требуется: «вы можете просто дожидаться уведомления от ЮKassa».

Что требуется от сайта:

• Адрес: «Требования к URL для уведомлений - протокол HTTPS и TCP-порт 443 или 8443.» Версия TLS/SSL - 1.2 или выше. Сертификат подойдёт любой: самоподписанный или выданный центром сертификации.
• Подтверждение: «Для этого ответьте кодом состояния HTTP 200.» Если ответ другой, сервис «продолжит доставлять уведомление в течение 24 часов, начиная с момента, когда событие произошло».
• Проверка подлинности: «проверьте его подлинность, например по статусу объекта или по IP-адресу. Это поможет защититься от атак, основанных на поддельных уведомлениях.»

Раздел Настройка HTTP-уведомлений разделяет два случая. Для готового решения: «достаточно выбрать ваш модуль из списка - настройки для уведомлений поставятся автоматически». Для самостоятельной интеграции: «для работы уведомлений нужно настроить их обработку на вашей стороне».

Почему это серверная часть: уведомление приходит на адрес и требует ответа, значит по адресу должна работать программа. Это вывод автора. Определение серверной части дано в статье о статическом и динамическом сайте. Если сайт сделан без серверной части, вопрос о приёме уведомлений нужно задать подрядчику до начала работы.

Что такое лимиты запросов и повтор запроса без двойной операции?

Коротко: Битрикс24 ограничивает интенсивность запросов в облачной версии и блокирует запрос, когда счётчик превысил порог. ЮKassa описывает идемпотентность: повторный запрос с теми же параметрами не повторяет операцию, и защита действует 24 часа. Оба правила относятся к своему сервису и общими для всех сервисов не названы.

Лимиты у Битрикс24. Раздел Лимиты REST API пишет, что лимиты интенсивности и ресурсоёмкости «действуют в облачной версии Битрикс24. В коробочной версии нагрузку настраивают на стороне сервера». Каждый запрос приложения увеличивает условный счётчик. Когда значение превышает порог, следующий запрос блокируется. Пороги зависят от тарифного плана:

Есть и ограничение по времени: в облачной версии один REST-запрос «должен выполниться не дольше чем за 60 секунд». Раздел предупреждает: «REST API не предназначен для массового и интенсивного обмена большими данными.» Если на сайте планируется выгрузка большого каталога или обмен учётными данными, спросите подрядчика, как обмен будет укладываться в лимиты.

Идемпотентность у ЮKassa. Документ о формате взаимодействия поясняет цель: «Такое поведение помогает избежать нежелательного повторения транзакций.» Пример оттуда: «если при проведении платежа возникли проблемы с сетью, и соединение прервалось, вы сможете безопасно повторить нужный запрос неограниченное количество раз». Срок назван прямо: «ЮKassa обеспечивает идемпотентность в течение 24 часов после первого запроса, потом повторный запрос будет обработан как новый.»

Там же описан случай, когда сервис за 30 секунд не смог дать точный ответ: он возвращает код 500, и «HTTP 500 не говорит об успешности или неуспешности выполнения вашей операции». Документ требует «сначала узнать результат обработки запроса и только после этого принимать любые решения, связанные с этой операцией». Для вашего сайта это вопрос подрядчику: что делает сайт, если ответа на запрос об оплате не пришло, и может ли покупатель заплатить за заказ дважды.

Что спросить у подрядчика до начала работы?

Коротко: девять вопросов ниже составлены из правил трёх источников. Каждый опирается на страницу сервиса, ответы по другим сервисам берутся из их документации. Вопросы идут от способа подключения и владельца кабинета к хранению ключа, тестовой среде и повтору запроса. Итог удобно записать в таблицу доступов, пример для магазина example.ru ниже.

1. Какие сервисы подключаются и каким способом: готовый модуль, код на сервере или блок на странице? Опора: документ ЮKassa о секретном ключе различает модуль и самописную систему; раздел Битрикс24 «С чего начать» называет вебхук, локальное и тиражное приложение.
2. На кого оформлен кабинет каждого сервиса и кто в нём Владелец или администратор? Опора: у ЮKassa приглашать пользователей могут Владелец и Управляющий; у Битрикс24 право создавать вебхуки открывает администратор.
3. Какую роль или права получит подрядчик и какие права получит ключ? Опора: роль Разработчик у ЮKassa; права вебхука и скоуп у Битрикс24.
4. Кто выпускает ключи и токены и в чьём кабинете? Опора: документы ЮKassa о секретном ключе, Яндекс Доставки о доступе и Битрикс24 о первом запросе.
5. Где хранится ключ и как убедиться, что его нет в открытом коде и журналах? Опора: ЮKassa просит не публиковать ключ; Битрикс24 перечисляет публичный код и логи.
6. Как ключ заменить и кто это делает? Опора: у ЮKassa перевыпуск, прежний ключ работает ещё 48 часов; по странице о доступе к API Доставки по России токен получают повторно после смены пароля.
7. Что проверено в тестовой среде и что в ней проверить нельзя? Опора: у ЮKassa карта и ЮMoney; у API Доставки по России (Яндекс Доставка) Москва.
8. Как сайт принимает уведомления и проверяет их подлинность? Опора: документ ЮKassa «Входящие уведомления».
9. Что будет при повторном запросе, при обрыве связи и при превышении лимита? Опора: идемпотентность и код 500 у ЮKassa; лимиты Битрикс24.

Результат разговора стоит записать в задание и договор. Как записать требование так, чтобы его можно было проверить, разобрано в статье о техническом задании на сайт; списка интеграций в ней нет. Права на результат разбираются в статье о договоре на разработку сайта.

Для вымышленного магазина example.ru таблица доступов может выглядеть так. Компания и сотрудники придуманы, правила замены взяты из источников.

Три строки показывают формат. Реальные ячейки зависят от договора с сервисом и от кабинетов, которые у вас уже есть.

Что проверить при приёмке?

Коротко: при приёмке стоит увидеть тест оплаты и доставки, запись о владельцах кабинетов и ключей, подтверждение, что секреты не лежат в открытом коде, и переключение с тестовых данных на настоящие. Каждый пункт опирается на источник, названный в конце строки: пункты 3 и 4 относятся к ЮKassa, пункты 6 и 7 к Яндекс Доставке.

1. Список подключённых сервисов совпадает с заданием, и у каждого записан владелец кабинета.
2. Пройден путь покупателя в тестовом режиме от корзины до оплаты; шаги описаны в статье об оплате.
3. Адрес для тестовых уведомлений отличается от адреса для настоящих операций; такой совет дан в документе ЮKassa «Тестовые магазины в ЮKassa».
4. Сайт переключён на идентификатор и секретный ключ настоящего магазина (быстрый старт ЮKassa).
5. Ключи и токены не лежат в публичном коде страниц и в журналах; пусть подрядчик покажет, где они хранятся (Битрикс24, ЮKassa).
6. Известно, что делать при смене пароля кабинета доставки (Яндекс Доставка).
7. Для доставки не по Москве согласован способ проверки: тестовая среда API Доставки по России (Яндекс Доставка) обрабатывает адреса только по Москве.
8. Понятно, как сайт поведёт себя при повторном запросе и при ответе с кодом 500 (ЮKassa, формат взаимодействия).

Интеграции с 1С, СДЭК, Ozon и amoCRM здесь не разобраны: ответы на вопросы по ним нужно брать из документации этих сервисов, и правила одного сервиса из этой статьи на них не переносятся.

Что про подключение сервисов сказано на главной BITSPARK?

На главной странице BITSPARK услуга «Интернет-магазин» описана так: «От 55 000 ₽ - каталог, корзина, оплаты и необходимые интеграции». Шаг «Разработка» там описан словами «Верстаем, программируем и подключаем сервисы. Технологии выбираем под задачу.»

Источники

• API - Глоссарий MDN Web Docs | MDN - определение API.
• JSON - Глоссарий MDN Web Docs | MDN - первое предложение определения.
• Введение в web APIs - Изучение веб-разработки | MDN - раздел о сторонних API.
• Формат взаимодействия с API ЮKassa - Прием оплаты по API ЮKassa - REST, JSON, секретный ключ, роль Разработчик, идемпотентность, ответ 500.
• Входящие уведомления - Прием оплаты API ЮKassa - события, настройка, подтверждение, проверка подлинности.
• Быстрый старт - Прием платежей в интернет-магазине по API ЮKassa - запросы с сервера, тестовый и настоящий магазин.
• Тестирование - Прием платежей по API ЮKassa - тестовый режим и что в нём проверяется.
• Секретный ключ для интеграции с ЮKassa - кому нужен ключ, выпуск, перевыпуск, удаление, модуль и самописная система.
• Роли пользователей в личном кабинете ЮKassa - роли и приглашение пользователей.
• Тестовые магазины в ЮKassa - совет об отдельном адресе для тестовых уведомлений.
• Настройка HTTP-уведомлений - адрес уведомлений, готовое решение и самостоятельная интеграция.
• REST API Битрикс24 и приложения для Маркет - главная страница документации: CRM.
• С чего начать | REST API Битрикс24 и приложения для Маркет - способы подключения, права, секреты, лимиты.
• Как получить доступ к REST API | REST API Битрикс24 и приложения для Маркет - способы получить доступ, пробный режим.
• Как выполнить свой первый запрос к API | REST API Битрикс24 и приложения для Маркет - входящий вебхук, права, секретный код.
• Лимиты REST API | REST API Битрикс24 и приложения для Маркет - лимиты в облачной и коробочной версиях.
• Как получить доступ к API | Яндекс Доставка - боевой и тестовый доступ, получение токена.
• BITSPARK - Digital studio - услуга «Интернет-магазин» и шаг «Разработка».

Обсудить проект в Telegram: t.me/billioniks