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.
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.
POST /api/v1/lead
Content-Type: application/x-www-form-urlencoded
click_id=EXAMPLE_CLICK_ID&email=synthetic%40example.invalid&first_name=ExampleReplace 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.