Why we have CAPI (and they don't)

    A plain-language explainer for owners comparing MenuLogic to Toast, Clover, DoorDash, and UberEats. Short version: server-side Meta tracking is an architectural choice, not a technical breakthrough — and the structure of marketplace platforms makes it almost impossible for them to ship it the way we do.

    What is CAPI? Meta's Conversions API. Instead of relying only on a browser pixel (which iOS, ad-blockers, and privacy modes routinely break), your server sends purchase events directly to Meta. The result: dramatically better ad attribution, ROAS measurement, and lookalike audience quality.

    TL;DR

    We own your storefront. They own a marketplace. When a customer checks out on MenuLogic, the transaction happens on your domain with your Meta Pixel ID and your CAPI token. When a customer checks out on DoorDash, it happens on their domain with their pixel — optimising their growth, not yours.

    The four reasons they can't ship it

    1. Domain ownership

    A pixel can only fire on the domain that owns the checkout. On MenuLogic, that's yourrestaurant.com. On DoorDash or UberEats, it's doordash.com. There is no clean way for your pixel to follow a customer through a checkout that lives somewhere else entirely.

    2. Pixel ownership conflict

    Marketplaces fire their own pixel on every order — because every order is theirs to attribute. Letting 50,000 restaurants each drop their own pixel into the marketplace checkout would pollute the marketplace's own ad data and create a measurement war. So they don't.

    3. Tenant-scoped tracking is an architecture decision

    Toast and Clover were designed as POS systems first. Their checkout layers don't have a concept of "per-merchant pixel ID and per-merchant CAPI token, injected at runtime, scoped to this tenant only." Retrofitting that into a checkout that powers 50k+ merchants is a multi-quarter project, not a weekend's work.

    4. Legal and compliance surface

    CAPI forwards hashed PII (email, phone) to Meta. Doing that across tens of thousands of merchants requires per-merchant consent, DPA updates, regional privacy review (GDPR, CCPA, Quebec Law 25), and a support org that can answer pixel questions. For a marketplace, the blast radius of a misconfiguration is enormous.

    Why this matters for your ad spend

    • iOS 14+ signal loss. Browser pixels miss a large share of conversions on iPhone. Server-side CAPI recovers them.
    • Accurate ROAS. If Meta sees only half your purchases, it under-reports revenue and you turn off ads that are actually profitable.
    • Better lookalike audiences. Meta's targeting model learns from the conversions you send it. More conversions = sharper targeting = lower cost per order.
    • Ad-blocker resilience. Server events bypass browser-side blockers entirely.

    What MenuLogic does differently

    • Per-restaurant Meta Pixel ID and CAPI access token, configured once in Integrations.
    • Server-side Purchase event fired for every paid order.
    • Multi-session attribution: if the converting session has no fbclid, we look back across the same device (7 days), then the same phone number, so an ad click on Monday still gets credited for a Friday order.
    • Deduplication via event_id so the browser pixel and server event don't double-count.
    • SHA-256 hashing of email and phone before transmission — raw PII never leaves the platform.

    The owner's one-liner

    "On a marketplace, every dollar I spend on Meta ads trains their algorithm. On MenuLogic, every dollar trains mine."

    Related