Я уже много лет пишу интерфейсы, периодически backend на javascript, но платформа 1С (ERP) как-то всегда обходила меня стороной. Я даже с SAP успел поработать за это время (правда с hybris, не ERP - немного это про другое). Но опыт интеграции с 1С появился совсем недавно.
По правде говоря, это даже не мой опыт, а моего коллеги бэкендера, за опытом интеграции которого мне довелось пристально понаблюдать. Поскольку сервер написан на Nestjs и я часто сам забирал на себя некоторые задачи по backend, думаю, я увидел достаточно чтобы собрать выжимку того, что мне было бы полезно знать изначально.

Единственное что я знал про 1С до начала работы с ним - это очень сложный механизм, внешне напоминающий свой собственный браузер со своим собственным фреймворком, что код 1С модулей пишется на своём языке стандарта ecmascript, на кириллице - по-русски, который после сурового frontend выглядит забавно.
И вот что ещё я теперь знаю:

Только вебхуки

У самого сервера 1С нет никакого внешнего API и после опыта интеграций со всякими "Мой склад" или "SafeRoute" или "Dadata", да короче любыми API, интеграция с 1С выглядит иначе - это неочевидно вот так сразу. Конечно вебхуки применяются повсеместно. Но как правило являются дополнением на случай, если в системе сервиса что-то поменялось и вам надо чтобы ваш backend об этом узнал без грабель поллинга через планировщики. Но с 1С это единственный способ общения. ТО есть по сути это вы делаете под него API и далее сервер 1C конфигурируется под односторонний обмен данных. Он будет ходить на ваш backend сервер и делать то, что вы ему позволите.
По поводу авторизации, как я понял, всё так же в ваших руках. Можно настроить как JWT и сессии, так и простой доступ по любому желаемому заголовку с ключом.

Следите за RESTful и сайдэффектами

1С ходит за данными в вашу систему по триггерам или планировщику, зависит от бизнес-логики. Бывает так, что это пайплайн асинхронных действий. Если на промежуточном запросе он поймает 5xx, то будет перезапускать весь пайплайн по новому до талого, пока не получит 200 на все запросы. То есть если пайплайн состоит из GET -> PATCH -> DELETE, и на DELETE он получит 500, то GET и PATCH будут ретраиться по новой.
Одна из горьких пилюль опыта с 1С - запрос, который выполнялся от 1С снова и снова из-за ошибки на другой точке, откатывал нам некоторые поля в сущностях базы, что триггерило некоторые непредвиденные действия в планировщике и вызвало критический баг в почтовых уведомлениях.
Поэтому очень важно следить за последовательностью действий и обрабатывать любые возможные кейсы, чтобы не провоцировать 1С на флуд запросами.

Готовьтесь к большим данным

Возможно это мой конкретный случай, но скорее всего вы всё же столкнётесь с тем, что 1С будет присылать вам очень крупные массивы данных, в моём случае были сущности с деревьями по 10 мегабайт и более. Всех их нужно было обработать, ещё и отрендерить на клиенте. Поэтому если ожидаете хотя бы потенциально, обработку крупных данных, применяйте stream-json на сервере и виртуализацию списков на фронте. К сожалению мы не сразу поняли с чем имеем дело, и то, что нам показалось сначала излишней оптимизацией, вылилось в heap out of memory, тормоза в браузере и как следствие ряд серьёзных доработок, особенно на фронте.

Не брезгуйте дополнительными флагами в сущностях

Обмен данными с ERP часто предусматривает синхронизацию между ним и вашей базой для утверждения, согласования, редактирования данных одной из сторон. Чтобы отдавать только те данные, которые были подвергнуты изменениям добавляйте дополнительные флаги и статусы. Как показала мне моя практика - их много не бывает. Это помжет вам оптимизировать размеры запросов и обработывать только то, что действительно требует синхронизации.

Надеюсь эти 4 важных тезиса помогут вам избежать неожиданностей и достичь катарсиса при разработке интеграции с 1С.