Embedded Marketo Engage form not updating after approving draft changes. No propagation after 3+ hours
Hi all, hoping someone can help with an embedded Marketo form revalidation issue.
CORE ISSUE
We embed a Marketo form in a Next.js site that is under development. It renders correctly with the fields from the first approved version. But when we edit the form (e.g. adding hint text to a phone field) and approve the draft, the change never appears, even 2+ hours later. The form status shows "Approved" and the "Updated at" timestamp reflects the approval, but the definition served to the page is still the previous approved version.
The only thing that makes the change show up is cloning the form, deleting the original, and re-embedding the clone (new form ID). Because embed IDs are referenced throughout the site, that isn't a viable workflow.
WHAT WE OBSERVE
GET {lp-domain}/index.php/form/getForm?...&form={id} keeps returning the PREVIOUS approved version. We polled from T+1min to T+2h; every response was stale.
EVIDENCE (server-side cache)
- The getForm response carries the header cached: true, and the payload matches the prior approved definition despite the fresh "Updated at".
- Hitting the raw Marketo pod (app-abNN.marketo.com) directly, bypassing our first-party LP domain entirely, returns a byte-identical stale payload (same content-length, same body) with the same cached: true. So the cache is at/behind the pod, not our domain.
- The getForm response has no cf-cache-status header (Cloudflare passes it through as dynamic via the “__cf_bm” cookie), so it isn't an edge cache either.
WHAT WE'VE RULED OUT
- Browser/HTTP caching: forms2 appends a unique `_` param per request; we also replayed getForm as JSONP with a fresh callback + `_` on every poll and it is still stale.
- CDN / first-party domain: two LP domains AND the raw pod domain all return the identical stale bytes (see Evidence).
- Embedding page URL: varying or removing the `url` param changes nothing.
- Our app: pasting the raw embed code on a bare page reproduces the same issue exactly.
KEY CLUE
A freshly created or newly cloned form serves its CURRENT definition immediately on first request. Only edits to an already-fetched existing asset fail to appear, which is consistent with a per-form-ID server-side definition cache that's populated on first fetch and never invalidated on approve.
QUESTIONS
1. Is there a documented propagation window / TTL for the getForm definition after approving a draft? What's considered normal?
2. Approving a draft: should it invalidate the `getForm` cache (the `cached: true` layer) for that form ID?
3. Is this a known issue on any pod, and is there a fix or Adobe ticket others have filed?
4. Is there any supported way to force-refresh a form's cached definition without re-cloning to a new ID?
5. For anyone who edits embedded (not landing-page) Marketo forms: what update latency do you actually see in practice?
Thank you!