Meta CAPI deduplication depends on event name and event ID consistency. If WordPress forms, webhook queues, or CRM retries generate a fresh event ID on every attempt, Meta can count the same lead more than once.
Use this for Gravity Forms, Elementor Forms, Contact Form 7, custom lead forms, queues, CRM webhooks, and server-side Meta Conversions API implementations.
Quick answer
Meta CAPI Form Retry Event ID Persistence should be handled with a narrow evidence-first workflow: generate once, persist event id, reuse on retry, then verify the result before making broader changes.
What to check first
- Create one event ID at form submit and store it with the entry before browser or server events send.
- Reuse the same event ID for browser Pixel and server CAPI events that represent the same lead.
- Persist retry count, processed state, last response, and Meta trace ID in the form entry or queue record.
- Avoid generating new IDs when a webhook, CRM sync, or queue worker retries the same submission.
- Separate later business outcomes such as qualified lead or sale into a deliberate event strategy.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Generate once | Create one event ID at form submit and store it with the entry before browser or server events send. | A retry of the same form entry uses the same event ID, not a new one. |
| Persist event ID | Reuse the same event ID for browser Pixel and server CAPI events that represent the same lead. | Browser and server Lead events share event name and event ID. |
| Reuse on retry | Persist retry count, processed state, last response, and Meta trace ID in the form entry or queue record. | Events Manager diagnostics do not show duplicate Lead events for the test submission. |
| Log state | Avoid generating new IDs when a webhook, CRM sync, or queue worker retries the same submission. | Queue logs explain whether a retry resent, skipped, or updated the event. |
Why this usually happens
- JavaScript creates the event ID in memory and the server cannot read it during retry.
- The queue job builds a new payload every time it runs.
- CRM retry logic sends another Lead event when it should update an existing record.
- Browser and server events use matching IDs but different event names.
- The team tests from Events Manager but never checks repeated production retries.
Field notes
- Store the event ID next to form entry ID and CRM lead ID. That makes duplicate diagnosis much simpler.
- If a lead becomes qualified later, decide whether that is a new event or an adjustment, not a repeat of Lead.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
event_id_persistence:
form_entry_id: GF-9104
crm_lead_id: CRM-88312
event_name: Lead
event_id: lead_GF-9104_20260705
pixel_sent_at: 2026-07-05T13:52:12Z
capi_sent_at: 2026-07-05T13:52:15Z
retry_count: 2
processed_state: sent_success
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Generate once
- Persist event ID
- Reuse on retry
- Log state
- Separate later outcomes
What to tell the client or owner
Tell the marketing owner where the duplicate came from and show the persistent event ID record for one test lead.
Production verification checklist
- A retry of the same form entry uses the same event ID, not a new one.
- Browser and server Lead events share event name and event ID.
- Events Manager diagnostics do not show duplicate Lead events for the test submission.
- Queue logs explain whether a retry resent, skipped, or updated the event.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix Meta Pixel and CAPI deduplication.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references
Check event time during retries
A stable event ID is only part of the proof. Use the Meta CAPI event time drift audit to confirm retries preserve the original action time and still describe the same lead.