Ошибка API 422 при отправке приглашений пользователям с существующим аккаунтом

Поддержка
1

Привет, команда,

Я пытаюсь настроить автоматизацию через Make.com, чтобы автоматически приглашать пользователей, купивших новый продукт в Kajabi, на Discourse, одновременно добавляя их в новую группу.

Проблема в том, что большинство (хотя и не все!) людей, совершающих эти покупки, уже имеют учётную запись на нашем форуме. Изучив ряд других постов об ошибке 422, включая ссылку ниже от 2021 года, я полагаю, что ошибка возникает из-за того, что электронные адреса уже связаны с учётными записями в Discourse.

Но с обновлённой системой приглашений, появившейся после того поста, у меня сложилось впечатление, что это больше не проблема, и я могу массово приглашать пользователей вручную через CSV-файл, чтобы добавить их в группу, даже если у них уже есть учётная запись, без возникновения ошибок, при этом приглашения будут отправляться тем, у кого её нет.

Итак, как исправить проблему? Я использую стандартный код API из вашей документации по API для приглашений, и он работал в прошлом. Я просто клонировал существующую (работающую) сценарий в Make и изменил название группы и стартовую тему. Для справки, вот код API, который я использую:

 	{
  "email": "user@host.com",
  "skip_email": false,
  "max_redemptions_allowed": 1,
  "topic_id": 782,
  "group_names": "Group-Name"
}

Достаточно ли просто изменить «false» на «true» в разделе «skip_email»? Или это приведёт к тому, что приглашения не будут отправлены тем, у кого нет учётной записи?

Я также вижу функцию PUT для добавления пользователя в группу, но я работаю только с письмами, отправленными через веб-хук из Kajabi, и не уверен, как настроить проверку электронных адресов на наличие имён пользователей для этого, поскольку, насколько я понимаю, я не могу использовать адрес электронной почты для функции PUT.

Спасибо за любую помощь!

2

О, я хотел добавить, что использовал одну и ту же ссылку вебхука от Make в строке исходящего вебхука для трёх отдельных продуктов в Kajabi. При этом эти продукты не покупаются вместе, так как они являются индивидуальными опциями «дополнительно». Я подумал, что проблема может быть в этом, но при тестировании сценария — отправке тестового исходящего вебхука от каждого продукта — ошибок не возникло. Ошибка появилась только тогда, когда реальный пользователь приобрёл продукт, и у этого пользователя уже был учётная запись.

3

Вы можете провести реверс-инжиниринг API Discourse, использовать маршрут admin/users и найти пользователя по его адресу электронной почты, а затем действовать дальше?

4

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

Почему это нельзя решить так же, как массовые приглашения через .csv, когда уже есть пользователи, не прерывая весь процесс с ошибкой? Казалось бы, должно быть простое решение — например, добавить в API условие «если пользователь существует, пропустить приглашение» или что-то подобное…