Development of an automated bridge: FB Instant Forms → CRM → Kameleo API → Broker API

Task essence:

It is necessary to implement a "live" lead registration system. The script must intercept leads from Facebook (Lead Ads), create them in our CRM, and conduct a full simulation of registration on the landing page through the anti-detect browser Kameleo (Playwright) or an equivalent to create a unique and consistent digital footprint that will pass the verification of advanced anti-fraud systems.

Technical process:

1. FB Lead Ads API

• Receiving leads from different Form_IDs via Webhooks / Graph API.
• Each form ID in the script configuration must be linked to its own offer and GEO.

2. Proxy management and unique session creation

• IP allocation: The script must call the proxy provider's API to reserve a unique residential or mobile IP address in the required GEO for the current lead.
• Kameleo Session & Unique fingerprint: Using this reserved IP, the script launches an iOS profile via the Kameleo API.
• Critical randomization: Each profile must use realistic and unique device parameters (CPU, memory, screen resolution, Device Memory) corresponding to real existing iPhone models. Repeating patterns are not allowed.
• Activation of spoofing: It is necessary to forcibly activate the intelligent spoofing function (Intelligent Canvas/WebGL Spoofing) via the Kameleo API to ensure a consistent and realistic digital fingerprint throughout the session.
• Current models: Device parameters (CPU, memory, screen resolution, Device Memory) must correspond to real existing iPhone models no older than the iPhone 14 series (iPhone 14, 14 Plus, 14 Pro, 14 Pro Max, and newer). Using repeating patterns is not allowed.
• iOS: Only versions 17.x and 18.x (released by 2026). Using iOS 15/16 on new iPhone models looks like manipulation.
• Browsers: The version of Chrome/Safari must not be older than the last two releases from the current date (check via Chromium Dash).

3. Session validation

• Check the created session on Pixelscan or an equivalent (e.g., browserleaks.com).
• Status must be Consistent.
• It is critically important to ensure that two consecutive leads have different yet consistent Canvas and WebGL fingerprints and look like a native fingerprint of the declared iOS device.

4. Registration (Touch emulation)

• The script via Playwright simulates "warming up" and accessing the landing page within an already launched session with a dedicated IP.
• Action emulation: The script enters data into the landing form, clicks "Register" (strictly via touchscreen.tap to simulate touch input on iOS).
• Important requirement for User-Agent and Fingerprinting: Since our CRM analyzes parameters precisely at the moment of transitioning through the auto-login link (not at the moment of lead transfer via API), it is extremely important that:
• The transition through the CRM masking link occurs strictly within the same Kameleo session in which the landing access was simulated.
• The Playwright script must ensure complete identity of User-Agent, IP (via the same proxy), and WebRTC parameters when transitioning through the link.
• The CRM anti-fraud system must see a "clean" digital fingerprint of the iOS device generated by Kameleo for the verification of the transition to be successful.

5. Integration with Broker and CRM API

• At the moment of clicking the button on the landing page, the script must initiate an API request to the broker (according to the broker's documentation), using THE SAME reserved IP address that is linked to the current Kameleo session.
• Receiving auto-login data (token/link) from the broker.
• Header management: When making API requests to the broker and transitions in the browser, it is prohibited to pass unnecessary or default headers (e.g., Referer or Origin) to minimize the digital footprint.
• The final transition in the Kameleo browser through the auto-login link to ensure the session is tied to the device.

6. Features of working with the CRM Redirect system and Anti-fraud

• Redirect logic: The auto-login link received from the broker is first saved in our CRM. The script receives an internal masking link from the CRM, not the direct link from the broker.
• Critical requirement for User-Agent and Fingerprinting: The transition through this CRM masking link must occur strictly within the same Kameleo/Playwright session.
• Synchronization: The CRM anti-fraud system analyzes parameters precisely at the moment of transitioning through the auto-login link. The script must ensure complete identity of User-Agent, single IP, and all fingerprints (Canvas/WebGL) between the moment of registration and the moment of transitioning through the link.
• Reporting: Updating the status in our rental CRM (lead ID, status with the broker, link to the log).

Technical Requirements

1. Device Parameters (Hardware Fingerprints)

Requirement: Each Kameleo profile must use realistic and unique device parameters (CPU, memory, screen resolution, Device Memory) that correspond to real existing iPhone models (e.g., iPhone 13 Pro with specific, non-template characteristics). Template patterns cannot be used.

• Developer action: The performer must develop a mechanism that generates or selects a unique set of parameters for each session, excluding the repetition of WebGL/Canvas bindings and screen resolutions between different leads.

2. Fingerprint Management (Canvas & WebGL Spoofing)

Requirement: It is necessary to ensure that Kameleo not only spoofs fingerprints but makes them unique for each session.

• Developer action: Within point 3 ("Validation"), the script must confirm that two consecutive leads have different yet consistent (passed Pixelscan/Browserleaks) Canvas and WebGL fingerprints. Repeating hashes are not allowed.

3. User-Agent Randomization

Requirement: Exclude the use of template or repeating User-Agent.

• Developer action: The performer must use dynamic User-Agent generation or a database of real UAs corresponding to the selected iPhone model and iOS version, with minimal, realistic variations (e.g., different browser build numbers) to avoid generator patterns.

4. Quality of Proxies and IP Addresses

Requirement: Solve the problem of IP/Geo mismatches and suspicious IPv6.

• Developer action: The performer must use high-quality mobile or residential proxies that guarantee accurate geographical correspondence of the GEO offer and show no signs of proxying for anti-fraud systems (clean IPs).

5. Requirements for proxy servers and IP addresses

It is critically important to use high-quality proxies to avoid detection of a bot farm.

Why this is important:

Broker anti-fraud systems are very sensitive to the quality of IP addresses. They look for Geo/IP mismatches (when the IP address does not match the declared GEO of the lead) and suspicious IPv6.

Key rule: The IP address used for lead registration via API (Sending IP) must match the IP address used for transitioning through the auto-login link (IP of following the link).

Proxy requirements:

• Proxy type: It is necessary to use residential or mobile proxies. The use of server (data center) proxies is strictly prohibited, as they are easily detected as automation tools.
• IP consistency: The performer must ensure a mechanism where the same IP address is used throughout the entire chain:
  1. For the API request for registration to the broker.
  2. For creating a profile in Kameleo.
  3. For transitioning through the auto-login link within the Playwright session.
• Exact GEO: The IP address must exactly match the geographical region of the offer and the lead data (e.g., Switzerland for CH). Cases like "Ashburn↔Yonkers" or "Pittsburgh↔Lititz" are not allowed and will lead to lead rejection.

Суть задачи:

Необходимо реализовать систему «живой» регистрации лидов. Скрипт должен перехватывать лиды из Facebook (Lead Ads), создавать их в нашей CRM и проводить полную имитацию регистрации на лендинге через антидетект-браузер Kameleo (Playwright) или аналог для создания уникального и консистентного цифрового следа, который пройдет проверку продвинутых антифрод-систем

Технический процесс:

1. FB Lead Ads API

• Прием лида из разных Form_ID через Webhooks / Graph API.
• Под каждый ID формы в конфигурации скрипта должен быть закреплен свой оффер и ГЕО.

2. Управление прокси и создание уникальной сессии

• Выделение IP: Скрипт должен обратиться к API прокси-провайдера для резервирования уникального резидентного или мобильного IP-адреса в нужном ГЕО для текущего лида.
• Kameleo Session & Уникальный фингерпринт: Используя этот зарезервированный IP, скрипт запускает профиль iOS через Kameleo API.
• Критическая рандомизация: Каждый профиль должен использовать реалистичные и уникальные параметры устройства (CPU, память, разрешение экрана, Device Memory), соответствующие реально существующим моделям iPhone. Повторение шаблонов недопустимо.
• Активация спуфинга: Необходимо принудительно активировать функцию интеллектуального спуфинга (Intelligent Canvas/WebGL Spoofing) через API Kameleo для обеспечения консистентного и реалистичного цифрового отпечатка на протяжении всей сессии
• Актуальные модели: Параметры устройства (CPU, память, разрешение экрана, Device Memory) должны соответствовать реально существующим моделям iPhone не старше iPhone 14-й серии (iPhone 14, 14 Plus, 14 Pro, 14 Pro Max и новее). Использование повторяющихся шаблонов недопустимо.
• iOS: Только версии 17.x и 18.x (вышедшие к 2026 году). Использование iOS 15/16 на новых моделях iPhone выглядит как манипуляция.
• Браузеры: Версия Chrome/Safari должна быть не старше двух последних релизов от текущей даты (проверять через Chromium Dash).

3. Валидация сессии

• Проверка созданной сессии на Pixelscan или аналоге (например, browserleaks.com).
• Статус должен быть Consistent (Согласованный).
• Критически важно убедиться, что два последовательных лида имеют разные и при этом консистентные отпечатки Canvas и WebGL и выглядят как нативный отпечаток заявленного iOS-устройства.

4. Регистрация (Сенсорная эмуляция)

• Скрипт через Playwright имитирует «прогревание» и заход на лендинг в рамках уже запущенной сессии с выделенным IP.
• Эмуляция действий: Скрипт вводит данные в форму лендинга, нажимает «Зарегистрироваться» (строго через touchscreen.tap для имитации сенсорного ввода на iOS).
• Важное требование по User-Agent и Fingerprinting:Поскольку наша CRM анализирует параметры именно в момент перехода по ссылке автологина (а не в момент передачи лида по API), крайне важно, чтобы:
• Переход по маскировочной ссылке CRM осуществлялся строго внутри той же сессии Kameleo, в которой имитировался заход на лендинг.
• Скрипт Playwright должен обеспечить полную идентичность User-Agent, IP(через тот же прокси) и WebRTC параметров при переходе по ссылке.
• Система антифрода CRM должна видеть «чистый» цифровой отпечаток iOS-устройства, сгенерированный Kameleo, чтобы верификация перехода прошла успешно

5. Интеграция с API Брокера и CRM

• В момент нажатия кнопки на лендинге скрипт должен инициировать API-запрос к брокеру (согласно документации брокера), используя ТОТ ЖЕ САМЫЙ зарезервированный IP-адрес, который привязан к текущей сессии Kameleo.
• Получение данных автологина (token/link) от брокера.
• Управление заголовками: При выполнении API-запросов к брокеру и переходов в браузере запрещается передавать лишние или дефолтные заголовки (например, Referer или Origin), чтобы минимизировать цифровой след.
• Финальный переход в браузере Kameleo по ссылке автологина, чтобы сессия закрепилась за устройством.

6. Особенности работы с Redirect-системой CRM и Антифродом

• Логика редиректа: Полученная от брокера ссылка автологина  сначала сохраняется в нашей CRM. Скрипт получает от CRM внутреннюю маскировочное ссылку, а не прямую ссылку брокера.
• Критическое требование по User-Agent и Fingerprinting: Переход по этой маскировочной ссылке CRM должен осуществляться строго внутри той же сессии Kameleo/Playwright.
• Синхронизация: Система антифрода CRM анализирует параметры именно в момент перехода по ссылке автологина. Скрипт должен обеспечить полную идентичность User-Agent, единый IP и всех отпечатков (Canvas/WebGL) между моментом регистрации и моментом перехода по ссылке.
• Отчетность: Обновление статуса в нашей арендной CRM (ID лида, статус у брокера, ссылка на лог).

Технические Требования

1. Параметры Устройства (Hardware Fingerprints)

Требование: Каждый профиль Kameleo должен использовать реалистичные и уникальныепараметры устройства (CPU, память, разрешение экрана, Device Memory), которые соответствуют реально существующим моделям iPhone (например, iPhone 13 Pro с конкретными, нешаблонными характеристиками). Нельзя использовать типовые шаблоны.

• Действие разработчика:Исполнитель должен разработать механизм, который генерирует или выбирает из базы данных уникальный набор параметров для каждой сессии, исключая повторение связок WebGL/Canvas и разрешений экрана между разными лидами.

2. Управление Отпечатками (Canvas & WebGL Spoofing)

Требование: Необходимо убедиться, что Kameleo не просто спуфит отпечатки, а делает их уникальными для каждой сессии.

• Действие разработчика: В рамках пункта 3 («Валидация»), скрипт должен подтверждать, что у двух последовательных лидов разные и при этом консистентные (прошедшие Pixelscan/Browserleaks) отпечатки Canvas и WebGL. Повторение хешей недопустимо.

3. Рандомизация User-Agent

Требование: Исключить использование шаблонных или повторяющихся User-Agent.

• Действие разработчика:Исполнитель должен использовать динамическую генерацию User-Agent или базу данных реальных UA, соответствующих выбранной модели iPhone и версии iOS, с минимальными, реалистичными вариациями (например, разные номера сборки браузера), чтобы избежать паттерна генератора.

4. Качество Прокси и IP-Адресов

Требование: Решить проблему IP/Geo несостыковок и подозрительных IPv6.

• Действие разработчика:Исполнитель должен использовать качественные мобильные или резидентные прокси, которые гарантируют точное географическое соответствие ГЕО оффера и не имеют признаков проксирования для антифрод-систем (чистые IP).

5. Требования к прокси-серверам и IP-адресам

Критически важно использовать высококачественные прокси, чтобы избежать обнаружения фермы ботов.

Почему это важно :

Антифрод-системы брокера очень чувствительны к качеству IP-адресов. Они ищут Geo/IP несостыковки (когда IP-адрес не соответствует заявленному ГЕО лида) и подозрительные IPv6.

Ключевое правило: IP-адрес, который используется для регистрации лида через API (Sending IP), должен совпадать с IP-адресом, который используется для перехода по ссылке автологина (IP of following the link).

Требования к прокси:

• Тип прокси: Необходимо использовать резидентные или мобильные прокси. Использование серверных (дата-центровых) прокси категорически запрещено, так как они легко детектируются как инструменты автоматизации.
• Консистентность IP: Исполнитель должен обеспечить механизм, при котором один и тот же IP-адрес используется на протяжении всей цепочки:
  1. Для API-запроса регистрации к брокеру.
  2. Для создания профиля в Kameleo.
  3. Для перехода по ссылке автологина внутри сессии Playwright.
• Точное ГЕО: IP-адрес должен точно соответствовать географическому региону оффера и данным лида (например, Швейцария для CH). Кейсы "Ashburn↔Yonkers" или "Pittsburgh↔Lititz" недопустимы и приведут к отклонению лида.