Facebook CAPI Tester
Sends a controlled Meta server event and exposes the response body you need for validation debugging.
Open tool >Meta payload troubleshooting
CAPI Event Rejected by Meta
Meta receives the server-side event, but rejects, drops, or marks it invalid because the payload, identifiers, consent context, or deduplication fields do not meet validation rules.
Introduction
Use this guide when your server clearly sends the event and Meta answers, but the response includes validation errors, warning-heavy payloads, or silent drops that keep the event out of the reporting path you expect. This is different from Facebook CAPI Not Firing, where the main question is whether the request leaves your stack at all.
The practical job is to turn a vague rejection into one reproducible evidence pack: raw Meta response, final landing URL, browser-side event proof, and the exact identifiers or fields that fail validation. Once those artifacts sit together, the owner of the payload can fix the specific gap instead of debating screenshots.
Symptoms
Meta rejection problems often hide behind partial success. The request returns a 200-style API response, someone assumes the event was accepted, and only later do you notice that Events Manager, match quality, or downstream optimization never reflects the conversion.
Start with a controlled replay in Facebook CAPI Tester, compare it against the browser evidence in Pixel Scanner, and keep Tracking Audit ready for escalations where redirects, click IDs, and payload ownership are split across teams.
- Meta answers the API request, but the event does not appear where the team expects it in Events Manager or diagnostics.
- The response includes messages about missing user data, invalid event_name, malformed event_time, action_source conflicts, or deduplication problems.
- Browser-side pixel evidence exists, yet the server event is treated as low-quality, unmatched, or invalid.
- The same integration worked before a form, CRM, consent, or routing change and now only some events are rejected.
Common causes
Most rejections come from payload quality rather than transport. Meta can receive the request but still distrust the event because required fields are malformed, identifiers do not line up with the landing-page evidence, consent state is inconsistent, or deduplication data conflicts with browser events.
Treat the issue as a chain-of-custody review for event data. The final landing URL, browser event, captured click ID, CRM or middleware transform, and outgoing server payload should all tell the same story about the user and the conversion.
- event_name, event_time, action_source, event_source_url, or custom_data fields are missing, stale, or formatted incorrectly.
- fbclid, fbc, external_id, email hashes, or phone hashes are absent, unhashed, double-hashed, or mapped to the wrong keys.
- A browser event and server event share the wrong event_id, reuse a stale ID, or fail deduplication because one side never received the same identifier.
- Consent logic, geo routing, or middleware strips user_data for some traffic segments while other segments still pass.
- The landing-page or CRM branch captures the click ID, but the payload builder sends a fallback value or empty field instead.
How to confirm the rejection
You need evidence from both sides of the stack: what the browser saw and what Meta rejected. Do not start by editing code blindly. First prove the final page, browser event, identifiers, and server response for the exact same test path.
A useful check leaves you with one sample event where every layer is documented: final URL, browser-side pixel state, click-ID capture, outbound payload, and Meta's direct response body.
-
Capture the raw Meta response
Replay the event in Facebook CAPI Tester and save the full response body, not just a green status banner.
-
Prove the browser-side reference event
Use Pixel Scanner on the same final landing page to confirm the browser-side Meta signal and the expected deduplication context.
-
Confirm identifiers survive the path
Trace the live URL in Redirect Checker and inspect the final landing query string in Click ID Extractor so you know whether fbclid or other identifiers ever reached the page.
-
Compare payload fields against the evidence
Check event_name, event_time, action_source, event_id, user_data, and custom_data against the landing-page evidence you just captured.
-
Choose the right branch before editing
If the request never leaves your stack, move back to Facebook CAPI Not Firing. If the landing page has fbclid but forms, CRM rows, or middleware lose it before payload assembly, branch into FBCLID Not Stored in CRM.
How to fix it
Fix the exact validation gap Meta points to, then rerun the same controlled event until the browser evidence, server payload, and Meta response agree. Avoid making three unrelated changes at once; otherwise you will not know which one restored acceptance.
When the rejection exposes a broader launch-quality problem, use How to validate click ID capture before launch and How to validate UTM links before launch to harden the page before new traffic reaches it.
Escalate through Tracking Audit when the owner of the broken field is unclear across media buying, CRM, and backend teams.
-
Normalize required event fields
Repair event_name, event_time, action_source, event_source_url, and any required custom_data formatting so Meta receives the payload in a valid shape.
-
Repair identifier capture and hashing
Make sure fbclid, fbc, external_id, email, phone, and other identifiers are captured once, transformed correctly, and hashed exactly where Meta expects them.
-
Align browser and server deduplication
Generate event_id values consistently and verify that both browser and server events share the same deduplication logic without reusing stale IDs.
-
Remove empty fallbacks and conflicting defaults
Strip middleware logic that sends blank placeholders, test values, or old schema fields when the real identifier is missing.
-
Retest the exact production path
Replay the same live landing URL, capture the new Meta response, and save the accepted payload together with the final redirect trace for future QA.
Tools that shorten the rejection loop
The fastest workflow starts with one direct replay and one browser-side check. That combination tells you whether the problem is a weak payload, a weak landing path, or a weak capture layer between them.
Do not send payload screenshots without path evidence. If the final landing page never received the same identifiers, Meta rejection is often only the last visible symptom.
Keep these tools in one runbook so reviewers can move from raw API response to URL evidence without reopening the incident from scratch.
Pixel Scanner
Confirms whether the landing page still produces the browser-side Meta context that the server event should match.
Open tool >Redirect Checker
Documents the real path and final URL before you blame payload validation alone.
Open tool >Click ID Extractor
Shows whether fbclid and related identifiers survive long enough to become usable server-side fields.
Open tool >Conclusion
A rejected Meta event is usually a data-quality failure, not a mystery. Once you line up Meta's response with the landing-page evidence and the exact payload, the repair path becomes concrete.
After the fix, keep one accepted sample payload, one matching browser event, and one final landing URL in your launch checklist. That turns future CAPI debugging into a fast comparison exercise instead of a fresh incident.
FAQ
Meta rejection FAQ
Can Meta reject an event even if the API request itself succeeds?
Yes. Transport success only proves the request reached Meta. The payload can still be invalid, weak, or unusable for attribution and deduplication.
Should I debug the payload before checking the landing page and click IDs?
No. If the landing page never received stable identifiers, the payload builder may be forced to send blanks or fallbacks. Check the path and browser evidence first.
When should I stop using this page and move to another guide?
Move to the not-firing guide when no request reaches Meta at all. Move to the CRM-storage guide when the page has the click ID but your forms, middleware, or CRM lose it before payload assembly.