Paste a Conversions API payload and check it against the rules Meta actually publishes: the seven day event_time limit, the nine valid action_source values, the identifiers each messaging channel requires, and which parameters must and must not be hashed.
It checks the rules Meta publishes that can be verified from a payload alone. Every check below maps to a sentence in Meta's developer documentation, quoted in the sources at the foot of this page.
| Check | Level | Based on |
|---|---|---|
event_name, event_time, action_source and user_data present | Error | Meta marks all four Required |
event_time is an integer, in seconds, not in the future, at most 7 days old | Error | The 7 day event_time rule |
event_time within 12 hours of the 7 day cutoff | Warning | A retry tomorrow would fail the whole request |
action_source is one of Meta's nine documented values | Error | The documented value list |
business_messaging carries a valid messaging_channel | Error | Conversions API for Business Messaging |
| The identifier pair that channel requires is present | Error | Meta's per-channel payload examples |
| Parameters marked "Hashing required" look like SHA-256 | Error | Customer Information Parameters |
| Parameters marked "Do not hash" are not hashed | Error | Customer Information Parameters |
fbc and fbp match the documented format | Warning | The fbp and fbc parameter guide |
event_source_url present on website events | Error | Meta states it is required for website events |
event_id present | Warning | Meta recommends it for deduplication |
value and currency present on a Purchase | Warning | Value optimisation and ROAS reporting |
LDU sent with a country | Error | Meta marks the country field required with LDU |
Because Meta rejects the request, not the row. One stale event in a batch of five hundred takes the other four hundred and ninety-nine down with it, and the failure looks like an outage rather than a data problem.
"The event_time can be up to 7 days before you send an event to Facebook. If any event_time in data is greater than 7 days in the past, we return an error for the entire request and process no events."
Messaging funnels hit this constantly, because a conversation that starts on Monday and produces a sale three weeks later has an event_time Meta will not take. The fix is not to backdate, which is inaccurate and against the terms you agree to when you set action_source. The fix is to send an in-window milestone event and keep the full-lifetime revenue picture in your own database. How each platform's limit compares is set out in conversion upload windows compared.
Meta splits user_data parameters into two groups and marks each one explicitly. Getting a field into the wrong group is the most common silent failure in a Conversions API integration, because the API accepts the event either way.
| Meta's marking | Parameters | Expected shape |
|---|---|---|
| Hashing required | em, ph, fn, ln, db, ge, ct, st, zp, country | 64 character lowercase hex SHA-256 digest |
| Do not hash | fbc, fbp, ctwa_clid, page_id, page_scoped_user_id, ig_sid, client_ip_address, client_user_agent | The raw value, unmodified |
Meta's framing of the split is: "Our systems are designed to not accept customer information that is unhashed Contact Information, unless noted below." The pass-through identifiers are the noted exceptions, and hashing them out of an abundance of caution destroys the match. Meta also warns separately that the click identifier "value is case sensitive - do not apply any modifications before using, such as lower or upper case."
A clean result is a reason to send, not a promise of a match. Four things are outside what any payload-shaped check can see:
action_source: "By using the Conversions API, you agree that the action_source parameter is accurate to the best of your knowledge." No validator can check that for you.This is not an official Meta tool and is not affiliated with or endorsed by Meta. Meta publishes its own Payload Helper and a test events view in Events Manager, and you should use both alongside this.
Every rule this validator applies comes from one of the pages below. Each was fetched and read on 14 August 2026.
event_time limit and its whole-request rejection, the GMT requirement, the nine action_source values, the deduplication rules, the event_source_url requirement for website events and the LDU country requirement. Page shows "Updated: Feb 12, 2026". developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/server-event. Checked 14 August 2026.user_data field this tool checks. Page shows "Updated: Jan 9, 2026". developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/customer-information-parameters. Checked 14 August 2026.fbc and fbp format checks, including the requirement that the creation time is in milliseconds. Page shows "Updated: Jan 9, 2026". developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/fbp-and-fbc. Checked 14 August 2026.messaging_channel values and the per-channel identifier requirements used in the business messaging checks. Page shows "Updated: May 5, 2026". developers.facebook.com/documentation/ads-commerce/conversions-api/business-messaging. Checked 14 August 2026.Last reviewed 14 August 2026
FlowTracker builds the payload for you: the right action source, the right identifiers per channel, and delivery inside each platform's window.
It checks a Meta Conversions API payload against rules Meta publishes: that event_name, event_time, action_source and user_data are present; that event_time is a Unix timestamp in seconds no more than 7 days old and not in the future; that action_source is one of Meta's nine documented values; that a business_messaging event carries a messaging_channel and the identifying fields that channel requires; and that every parameter Meta marks "Hashing required" looks like a SHA-256 digest while every parameter marked "Do not hash" does not.
No. The validator is JavaScript running in this page. Your payload is parsed and checked locally and is never transmitted to FlowTracker or to any third party. You can confirm this by opening your browser's network panel while you run it, or by loading the page and then disconnecting from the internet.
Because Meta rejects the request rather than the row. Meta's server event parameters reference states: "The event_time can be up to 7 days before you send an event to Facebook. If any event_time in data is greater than 7 days in the past, we return an error for the entire request and process no events." Filtering stale events before you send is the only safe approach.
Meta marks these "Hashing required": em, ph, fn, ln, db, ge, ct, st, zp and country. Meta marks these "Do not hash": fbc, fbp, ctwa_clid, page_id, page_scoped_user_id, ig_sid, client_ip_address and client_user_agent. Hashing a do-not-hash field is accepted by the API and matches nothing, which is why this validator flags it.
Meta defines business_messaging as "Conversion was made from ads that click to Messenger, Instagram or WhatsApp" and chat as "Conversion was made via a messaging app, SMS, or online messaging feature." A conversion from a click-to-WhatsApp ad uses business_messaging with messaging_channel set to whatsapp. A Telegram conversion is not a Meta messaging surface, so chat is the applicable value.
No, and it does not claim to. It checks the documented rules that are checkable from the payload alone. It cannot verify your dataset ID, your access token, your permissions, whether your hashed values match anyone, or any rule Meta enforces but does not publish. Treat a clean result as a reason to send, not as a guarantee of a match.
No. It is a free tool built by FlowTracker from Meta's public developer documentation, and it is not affiliated with or endorsed by Meta. Meta provides its own Payload Helper and Events Manager test events tool, and you should use those as well.