Статусы приходят от партнёров; конверсии уходят в твой источник и рекламные кабинеты.
Здесь встречаются два потока. Статусы приходят от рекламодателя; конверсии уходят тем, кому нужно знать — твоему трафик-источнику и твоим рекламным кабинетам. Это разные направления, настраиваются независимо.
d0pe тянет статус по расписанию: зовёт status-API партнёра за диапазон дат, матчит каждый элемент к твоему лиду по external id, маппит статус партнёра на твои внутренние (авто-создавая неизвестные), и на FTD поднимает лид в депозитора и пишет депозит. Упавший или непарсимый пул не трогает ничего — лид держит последний хороший статус. Устойчивый partner_id держит синк рабочим, даже если исходную кампанию позже удалят.
Когда лид доходит до события — регистрация, отклонён, звонок, депозит (FTD, главная цель) или редепозит — d0pe отбивает подходящие правила постбеков. Одно событие, например депозит, может разойтись сразу по нескольким получателям.
Правило можно сузить условиями. Особенно это важно на событии «звонок»: оно возникает на каждое изменение статуса у партнёра, и без условий трекер узнаёт про недозвоны и неверные номера ровно так же громко, как про одобренные лиды.
Сузить можно по категории колл-статуса — те самые Good / Bad / Trash / Недозвон, которые ты задал в Настройках; ссылка идёт по имени категории, поэтому переименование сырого статуса автоматически переразложит правила — либо по конкретному статусу, стране, партнёру или потоку. Условия складываются по «И», а пустые условия означают, что правило срабатывает на всё.
Несколько правил могут делить одно событие и один адаптер, различаясь только условиями, — так что хорошие звонки уходят в один трекер, а отказы в другой.
В Postbacks → Telegram bot подключи бота (создай через @BotFather, вставь токен — он проверяется при сохранении, хранится шифрованным и больше не показывается) и дай каждой группе или каналу имя. Добавь бота в чат, нажми Test, чтобы убедиться, что он может писать, — и любое правило постбека сможет слать в этот чат по имени. Сообщение — шаблон с теми же макросами, что и URL: «Новый {status} лид из {country}, выплата {payout}» — с опциональной разметкой HTML или MarkdownV2. Send test сначала шлёт с образцовыми данными — там и всплывёт ошибка разметки, а не на живом лиде.
У каждого URL- и Telegram-правила есть кнопка Send test: шлёт один раз с образцовыми данными по тому же пути, что и реальное событие, и показывает результат — доставлено со статус-кодом либо причину отказа. Исходящие URL сперва проверяются: постбек на приватный или внутренний адрес отклоняется, чтобы CRM нельзя было превратить в прокси к тому, к чему доступа быть не должно.
Оба потока выше — это push. Есть третий, и он pull: поставщик трафика может сам спросить текущее состояние отправленных им лидов через GET /api/ext/leads, авторизуясь тем же токеном, которым отправляет. Видит только свои лиды, может фильтровать по периоду и статусу (LEAD, FAILED, DEPOSITOR, UNASSIGNED), а по отклонённому бренду лиду получает полный ответ партнёра — то есть причину, не спрашивая тебя. Пригодится, когда провайдеру нужна сверка, а не пособытийные постбеки; точный контракт — в справочнике API.
Правила — командные (глобальное правило владельца/тимлида) или личные правила байера. Байер, создавший хотя бы одно правило для получателя, забирает этот канал целиком на этом событии: его правила заменяют командные, а не работают вместе с ними — иначе каждая конверсия уходила бы дважды. Конфиги адаптеров держат секреты (токены CAPI, API-ключи) и шифруются на хранении; лог на каждый лид показывает каждый отбитый постбек. Трафик-провайдеры — inbound-only: постбеки провайдера — это просто правила его owner-user, показанные по провайдеру.