Documentation sections

Reliable lead data intake

How the prepared queue preserves form data while a click or the analytics store is unavailable.

These features are available starting with release 20261101.1. Update the tracker to use them.

Warning.

Since release 20261101.1, this queue applies to /api/v1/lead. It does not restore the leads.php file journal.

Form request

Send a POST to /api/v1/lead with click_id (or subid or aff_sub) and at least one of email, phone, first_name, last_name. Aliases name and fname are accepted for first_name, and lname for last_name. GET remains compatible with image pixels, but POST keeps contacts out of the URL.

If the offer's affiliate network has a secret, provide it as secret. Otherwise, the traffic source secret applies. Send the secret from the page's server; do not embed it in browser JavaScript.

http
POST /api/v1/lead
Content-Type: application/x-www-form-urlencoded

click_id=EXAMPLE_CLICK_ID&email=synthetic%40example.invalid&first_name=Example

Replace EXAMPLE_CLICK_ID with a real visit ID. The example does not create a click.

What HTTP 200 means

HTTP 200 confirms that PostgreSQL has saved the data, even if analytics ingestion is delayed. GET returns a pixel; POST returns ok. A persistence failure or a full queue returns 503 with Retry-After: 5; retry the same request later. An invalid secret returns 401.

Before analytics contains the click, intake requires a separate signed receipt proving that the visit was recorded durably. An arbitrary ID is not accepted. Without a valid receipt, the previous click wait and error response remain in effect. Failure of this additional check does not stop traffic.

Waiting and retries

An unconfirmed full click and offer-transition context can wait for up to 24 hours. If storage responds after that period but the required record is still absent, the job becomes click_expired and its queued contacts are erased. Once the context is confirmed, a temporary storage failure has no such expiry: data stays queued until delivery succeeds.

Requests for one click are processed in acceptance order. Adjacent identical requests are combined. Without a verified secret, new values only fill empty fields. With a secret, supplied fields replace old values while omitted fields are retained. Corrections A → B → A preserve the final A. Recovery after a write/acknowledgement failure does not resend a form or postback.

CAPI preparation includes accepted queued data even before it appears in analytics. Outgoing events still follow the license and their delivery rules.

Limits and diagnostics

Field limits in bytes: email 512, phone 128, first and last names 256 each. The queue accepts up to 32 pending requests per click and 100,000 per workspace. Payloads are encrypted with the installation key; preserve that key with backups. Source and network secrets are not stored in the queue.

An owner or administrator can call GET /api/v1/maintenance/lead-queue. The response contains only counts: waiting_for_click, waiting_for_storage, click_expired or click_context_changed, without contact data. An unconfirmed context belonging to a different workspace or campaign is never applied.

Updated Need help? ↗