Как тянуть статусы и депозиты обратно

По полям: второй эндпоинт, который рассказывает, что стало с лидом после отправки.

Отправить лид — половина дела. Вторая половина — узнать, что с ним сделал колл-центр партнёра: ответил, не заинтересован, задепозитил. Это приходит со второго эндпоинта, который опрашивается по расписанию, и это самая насыщенная полями часть шаблона. Разберём их в том порядке, в каком спрашивает форма.

Он опционален. Пропустишь — доставка всё равно работает, просто не увидишь колл-статусов и депозитов, а конверсия останется пустой.

Эндпоинт и его окно

Pull URL, метод и формат тела берутся из доки партнёра — так же, как для отправки. GET подходит: тело запроса становится query-строкой.

Большинству партнёров нужен диапазон дат, поэтому в теле используются макросы окна, которые CRM подставляет на момент опроса. Бери тот, что совпадает с их форматом: {from} / {to} дают «YYYY-MM-DD HH:MM:SS»; {from_date} / {to_date} — только дату; {from_iso} / {to_iso} — ISO-8601 UTC с Z на конце; {from_ddmmyyyy} / {to_ddmmyyyy} — день первым. Всё остальное в этом теле — фиксированный type=3, id аккаунта — пишешь как есть.

Опрос идёт по возрасту лида: свежие проверяются каждые двадцать минут, старые — всё реже, чтобы месячный лид не дёргался с той же частотой, что сегодняшний.

Авторизация автоматическая

Пул переиспользует основную авторизацию шаблона и те же доступы партнёра — вводить заново ничего не нужно. «Extra headers» — только для несекретного литерала, который дополнительно требует эндпоинт, вроде Accept: application/json, и у большинства партнёров это поле остаётся пустым. Никогда не клади туда API-ключ: он осядет в шаблоне фиксированным текстом, общим для всех партнёров на этом шаблоне.

Как в их ответе находится твой лид

Партнёр возвращает пачку. Три поля объясняют CRM, как её читать:

• List path — где в ответе лежит массив элементов, например rows или data.leads. Оставь пустым, если весь ответ и есть массив. Словарь с ключами-id тоже работает.
• Match field — поле внутри элемента с собственным id лида у партнёра. Оно обязано совпадать с тем, что при отправке сохранил «Lead ID path», — именно так строка привязывается к твоему лиду. Ошибка здесь означает, что статусы не обновятся никогда.
• Status field — где внутри элемента лежит значение статуса. Dot-path работает, например registration.rawStatus.

Дальше маппинг статусов переводит их словарь в твой — самое ценное поле в этой секции, ему посвящена отдельная страница ниже.

Как отличить депозит от статуса

Партнёры сигналят о первом депозите одним из двух способов, и форма поддерживает оба, потому что выбирать не тебе:

• Значением статуса — их статус становится чем-то вроде «Deposited». Это значение вписывается в «Deposit/FTD statuses».
• Отдельным флагом — поле вроде isDeposited: true или hasFTD: 1 рядом со статусом. Поле идёт в «Deposit field», а значения, означающие «да», — в «Deposit field values».

Если партнёр делает и то и другое — заполняй оба: они проверяются независимо, а найденный любым способом депозит записывается один раз.

Когда депозиторы приходят с другого эндпоинта

Некоторые партнёры разделяют: один эндпоинт под колл-статусы, другой под депозиторов, или тот же URL с другим параметром (acq=0 против acq=1). Для этого и нужна вторая, отдельная секция депозитного пула — заполняется только в таком случае. Большинству интеграций она не нужна, оставляй выключенной.

Как проверить, что работает

• Статусы вообще не меняются — match field не соответствует id лида, сохранённому при отправке. Это причина с большим отрывом.
• Часть лидов обновляется, часть никогда — те лиды отправлены до настройки пула, либо окно партнёра не достаёт так далеко назад.
• Статусы приходят, но выглядят как формулировки партнёра — пустой маппинг статусов.
• Депозиты не фиксируются — сигнал депозита второго типа, либо значение не совпадает точно.