Conversions API Built Server-Side, With CRM Stage Events

A Conversions API that mirrors your browser pixel and stops there is a deduplication exercise, not a measurement change. The install we ship sends hashed email, phone in E.164 form, external_id, fbp, fbc reconstructed from fbclid at first touch, and client IP and user agent taken from the request, which holds Event Match Quality at 8 or above on the events we control. Then it sends the events your browser never sees: the stage changes in your CRM. Where the events come from: We build an endpoint on your infrastructure, in Node or Python, whichever your team already deploys. It receives from your site, your backend and your CRM webhooks, hashes on the way out, and posts to Meta, the TikTok Events API and LinkedIn CAPI from a single payload contract. No partner connector sitting in the middle owning your data. When RD Station moves an opportunity from Lead to Qualificado, or Pipedrive marks a deal Won 40 days after the click, that event goes back carrying the original lead identifier and the true event time, and the optimizer finally learns which click was worth anything. WhatsApp: In Brazil this is the whole conversation. Click-to-WhatsApp ads hand you a ctwa_clid, and if nobody carries it into the CRM record the channel is invisible in reporting and useless for optimization. We wire it from the Cloud API webhook into the lead record, so a deal that started in a WhatsApp thread reports as the deal it is rather than as unattributed direct traffic. Deduplication and event design: One event_id generated server-side and passed to the browser, never the reverse. A named event schema carrying the parameters your reporting will need in six months, agreed in writing before we build anything. Value assigned at qualified stages rather than at form fill, so bidding stops chasing whoever fills forms fastest. The schema is a document you own and can hand to the next agency. LGPD: Consent state travels with the event and is enforced at the endpoint, not in a tag manager any marketer can edit. Hashing happens before anything leaves your network. We write the retention rule and the data-subject deletion path into the endpoint itself, because you will eventually be asked to demonstrate both. Not included: We do not buy or configure your consent management platform, we do not build a warehouse, and we do not produce an attribution model. If your CRM has no stage discipline, where everything sits in Lead forever and Won gets filled in by hand twice a quarter, fix that first. The install will be technically correct and will teach the optimizer nothing. Who this is not for: Ecommerce checkouts where Purchase fires on a thank-you page and the revenue question is already answered by the browser. You will gain match quality and little else, and there are cheaper ways to buy that. This engagement pays when the revenue event lands 30 to 180 days after the click, inside a system Meta cannot see. What you receive: The endpoint source in your repository, the event schema, the CRM webhook configuration, a deduplication test evidenced from Events Manager, a 14-day verification window in which we watch match quality and drop rates daily, and a written rollback path. Your developers can maintain it without us, which is the point of building it this way.