Facebook CAPI 400 Bad Request Fix for Make.com
Last Updated: May 2026Question: What causes a Facebook CAPI 400 Bad Request in Make.com?
Quick Answer: A Facebook CAPI 400 error is almost always caused by an improperly formatted JSON payload. This occurs when you fail to wrap the event in the mandatory ‘data’ array, send unhashed or un-normalized user data (like raw emails), or provide an invalid UNIX timestamp format in your automation engine.
This deployment guide shows how to instantly fix the Facebook Conversions API integration error when building a custom server-side tracking system in Make.com, including resolving invalid parameter issues, fixing payload formatting, and accurately hashing your tracking events.
If your Make.com HTTP module is glowing red with a 400 status code, Meta’s API is actively rejecting your server-side conversion. You are currently dropping data.
This Guide Is For:
- Media buyers scaling server-side events
- Agency owners troubleshooting broken tracking
- Operators building Make.com data pipelines
Meta’s Conversions API strictly validates every single HTTP POST request. This usually happens after operators blindly copy payload examples generated by ChatGPT without understanding array structures. Here is the exact fix.
Why You Get a Facebook CAPI 400 Error
If you check your HTTP module output inside Make.com, you are likely seeing this exact error response from the Meta Graph API endpoint:
{
"error": {
"message": "Invalid parameter",
"type": "OAuthException",
"code": 100,
"error_subcode": 2804019,
"is_transient": false,
"error_user_title": "Missing required parameter",
"error_user_msg": "A required parameter is missing from your request."
}
}Because Facebook’s server could not parse your data, the request dies. The most common triggers are:
- Invalid JSON structure: Missing the mandatory
dataarray wrapper around your event object. - Unhashed PII: Sending raw emails instead of SHA-256 formatted hashes, or failing to normalize the string first.
- Wrong event_time format: Sending standard dates instead of a 10-digit UNIX timestamp.
Before (Fails):
- Missing data array
- Plain text email sent to Meta
- Date mapped as “MM/DD/YYYY”
After (200 OK):
- Valid JSON payload wrapper
- Trimmed, lowercased, SHA-256 hashed data
- Accurate UNIX timestamp
The Quick Fix (Valid JSON Payload)
Copy and paste this exact structure into your Make.com HTTP module’s “Request content” field. Notice that the event is strictly wrapped inside the data array.
{
"data": [
{
"event_name": "Purchase",
"event_time": {{formatDate(now; "X")}},
"action_source": "website",
"user_data": {
"em": ["{{sha256(lower(trim(1.email)); "hex")}}"],
"ph": ["{{sha256(1.phone; "hex")}}"],
"client_ip_address": "{{1.ip_address}}",
"client_user_agent": "{{1.user_agent}}"
},
"custom_data": {
"currency": "USD",
"value": {{1.purchase_value}}
}
}
]
}Step-by-Step Fix (Make.com Context)
Step 1: Check Your HTTP Module Headers
Ensure your Make.com “Make a request” HTTP module is configured exactly like this:
- URL:
https://graph.facebook.com/v19.0/{{YOUR_PIXEL_ID}}/events?access_token={{YOUR_ACCESS_TOKEN}} - Method: POST
- Headers: Add a header with Key:
Content-Typeand Value:application/json

Correct mapping for the Make.com HTTP module pointing to the Graph API.
Step 2: Fix Payload Mapping & Hashing
Inside the JSON structure, you cannot pass a raw email address. To satisfy Meta’s Event Match Quality (EMQ) standards, you must use Make.com’s native string functions to normalize the data (lowercase and trim whitespace) before hashing it.
Use this exact formula syntax in Make.com for the email field: {{sha256(lower(trim(1.email)); "hex")}}
Step 3: Validate Your UNIX Timestamp
The event_time parameter must be a 10-digit UNIX timestamp. Use Make.com’s {{formatDate(now; "X")}} function to convert the current execution time into a compliant UNIX string.
Common Mistakes Checklist
Before running your scenario again, verify you haven’t made these typical operator errors:
- Sending a plain text email instead of a hashed string.
- Forgetting to wrap the
emandphvalues in brackets. They must be arrays:"em": ["hash"]. - Omitting the
action_sourceparameter (usually set to"website"). - Leaving a trailing comma after the last item in a JSON object (a strict JSON syntax error).
Production Deployment Warnings
- Event ID Deduplication: If you are firing both browser and server events, you MUST pass a matching
event_idin your payload. Without it, Meta will double-count your purchases and destroy your ROAS reporting. See our server-side architecture guide for implementation. - API Throttling: If you continuously spam the Graph API with malformed payloads during testing, Meta will temporarily throttle your token.
- Empty CRM Fields: If your payload intermittently fails in production, check whether empty string values for phone numbers are being passed. Wrap optional arrays in fallback logic.
Advanced Operator Diagnostics: Still Getting a 400?
If you have corrected the JSON wrapper and hashed the PII but the HTTP module is still failing, check these deeper structural issues:
- Case-Sensitive Event Names: Meta requires standard events to be capitalized. Sending
"event_name": "purchase"will fail. It must be"Purchase". - Stale Access Token: The System User access token generated inside Meta Business Manager does not last forever unless explicitly set to never expire. Check if your token was revoked.
- Stray Test Codes: If you mapped a
test_event_codeduring testing but left it in the payload for a live production environment, Meta will frequently reject the request.
How to Test the Payload
Do not test blindly in production. Open your Meta Events Manager, click on your Pixel, and navigate to the Test Events tab. Copy your unique test_event_code.
Add this code to your JSON payload right beneath the action_source line like this: "test_event_code": "TEST81014",. Run the Make.com module. You can also verify your JSON structure using the official Meta Payload Helper.

A successful test inside Meta Events Manager confirming valid server-side event tracking.
If the payload is correct, the module will turn green and return an HTTP 200 OK status code, completely resolving the Facebook CAPI 400 Bad Request Make.com integration issue.
Frequently Asked Questions
A Facebook CAPI 400 error is almost always caused by an improperly formatted JSON payload. This includes missing the required ‘data’ array wrapper, sending unhashed PII, or providing an invalid UNIX timestamp.
Yes. All Personally Identifiable Information (PII) such as email (’em’) and phone number (‘ph’) must be normalized (lowercased and trimmed) and hashed using SHA-256 before being sent to the Meta API.
Yes. By using the standard HTTP ‘Make a Request’ module and formatting the JSON correctly, Make.com can execute high-volume server-side tracking.
A valid Facebook CAPI response returns an HTTP 200 OK status code, along with a JSON payload containing the ‘events_received’ metric.
Don’t Build This From Scratch
Most operators quit at this exact step—this is where DIY tracking systems usually fail.
This JSON error is just one piece of the puzzle. The full pipeline includes webhook capture, event deduplication, and CRM attribution logic.
Get the Complete Make.com Attribution Blueprint →