Sending Custom Object data via webhook when multiple COs can fire concurrently for the same lead | Community
Skip to main content
Level 2
June 24, 2026
Question

Sending Custom Object data via webhook when multiple COs can fire concurrently for the same lead

  • June 24, 2026
  • 1 reply
  • 44 views

Hi all,

I'm building an integration where Marketo sends a webhook payload (via Mulesoft) every time a lapse-related email goes out, and the payload needs several fields from a Custom Object called lapseDetails.

From this thread I know CO field tokens don't resolve in webhook payloads — only {{lead.X}} and the standard namespaces do. The two known workarounds are: (1) copy CO data to lead fields via Change Data Value, or (2) have the webhook receiver loop back via REST.

Where I'm stuck:

Option 1 has a race condition. Producers can have multiple lapseDetails CO records insert concurrently (one per policy lapsing). Each insert fires its own campaign run for the same lead, and the flow needs a 1-minute wait (for an OAuth token). Both concurrent runs write to the same lead fields, so by the time the webhook fires, only the last CO's values remain. Both webhooks ship the same payload — one CO gets archived twice, the other lost.

Question:

Is there a Marketo-side pattern for sending the specific triggering CO's fields out via webhook when multiple CO inserts can happen for the same lead in quick succession? Ideally I'd like to solve this within Marketo rather than push the work to the integration team.

Thanks in advance.

    1 reply

    SanfordWhiteman
    Level 10
    June 24, 2026

    | From this thread I know CO field tokens don't resolve in webhook payloads...

     

    That’s not actually true. The {{trigger.tokens}} at least for dedupe fields are usable in webhook payloads (as long as the campaign triggers on Added to Custom Object, of course).

     

    UPDATE: all user fields (i.e. not Created At, Updated At, or Marketo GUID, but everything else) are available in tests I just ran! So you should be fine unless the GUID is necessary.

     

    P.S. I’m not sure why you’d ever use a Wait step in the scenario you describe. Wait steps are never necessary with webhooks, as you can trigger on Webhook is Called. Nevertheless, a setup that relies on getting an OAuth token from one webhook to use in another is inherently fragile, and triggering on Webhook is Called doesn’t solve your race condition anyway.