Facebook CAPI 400 Bad Request in Make.com: The Fix (2026)

1. What a Facebook CAPI 400 Bad Request Actually Means

The first mistake is treating every Meta API failure as a payload-formatting problem. A Make.com scenario can fail because the request body is invalid, but it can also fail because the token is invalid, the connection no longer has the required permissions, the Pixel is inaccessible, or a required parameter is missing.

That is why the first debugging action should always be to inspect the complete response, including the message, type, code, error_subcode and trace/request identifiers when they are returned.

{
  "error": {
    "message": "Invalid parameter",
    "type": "OAuthException",
    "code": 100,
    "error_subcode": 0,
    "is_transient": false,
    "error_user_title": "Invalid parameter",
    "error_user_msg": "Check the parameters in the request"
  }
}

2. Native Make.com Module vs HTTP Module

There are two legitimate ways to build a Meta Conversions API scenario in Make.com. The correct debugging approach depends on which one you are using.

When the native Make module is the right choice

• You want the shortest no-code path.
• Your event structure fits Make’s Facebook Conversions API fields.
• You do not need unusual API parameters or custom request transformations.
• You want Make to manage the Meta connection rather than manually constructing the endpoint.

When the HTTP module is useful

• You need a custom request body.
• You are combining data from several systems.
• You need custom business logic before the event is sent.
• You want direct control over the Graph API request and response.
• You are debugging the exact JSON Meta receives.

3. The Correct Meta Conversions API Payload

For a direct Graph API request, Meta’s standard structure is a top-level data array containing one or more server-event objects.

For a website Purchase event, the event normally includes the event name, actual event timestamp, user data, custom data, website action source and event source URL. A stable event_id should also be used when you are coordinating the browser Pixel and server event.

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": {{UNIX_EVENT_TIME}},
      "event_id": "{{STABLE_EVENT_ID}}",

      "user_data": {
        "em": [
          "{{SHA256_NORMALIZED_EMAIL}}"
        ],
        "ph": [
          "{{SHA256_NORMALIZED_PHONE}}"
        ],
        "client_ip_address": "{{CLIENT_IP}}",
        "client_user_agent": "{{CLIENT_USER_AGENT}}",
        "fbp": "{{FBP_IF_AVAILABLE}}",
        "fbc": "{{FBC_IF_AVAILABLE}}"
      },

      "custom_data": {
        "currency": "USD",
        "value": 142.52,
        "content_ids": [
          "PRODUCT-123"
        ],
        "content_type": "product"
      },

      "action_source": "website",
      "event_source_url": "{{EVENT_SOURCE_URL}}"
    }
  ]
}

Graph API endpoint

If you are using Make’s HTTP module, use the current Graph API version documented by Meta at deployment time rather than hardcoding an old version into an evergreen article.

POST
https://graph.facebook.com/v{API_VERSION}/{PIXEL_ID}/events

Keep the access token out of your public website code. Store it in the protected Make connection or other secure secret mechanism available to your infrastructure.

4. The Fields That Matter Most

Purchase events need purchase data

For a Purchase event, include the relevant monetary information such as value and currency. If you also know the product IDs, content type or contents, send those as appropriate to your implementation.

5. SHA-256 Hashing and Normalization

This is one of the most common places where a technically valid event becomes a poor matching event.

For direct HTTP implementations, customer identifiers that Meta expects hashed should be normalized first and then SHA-256 hashed. Browser context such as IP address and user agent is not treated like email or phone and should not be replaced with a hash.

Email example

Raw email
Jane.Doe@example.com

Normalize
jane.doe@example.com

Hash
SHA-256(normalized email)

Send
64-character hexadecimal SHA-256 value

Phone normalization

Phone numbers should be converted into a consistent international representation, normally including the country calling code, before hashing.

Raw
+1 (415) 555-2671

Normalized
14155552671

Then
SHA-256(normalized phone)

Do not copy Google Ads normalization rules word-for-word into Meta CAPI. They are separate platforms with separate specifications.

6. event_id: The Part That Stops Pixel + CAPI Double Counting

A correct 400 fix can still leave you with broken measurement if the same conversion is sent from both the browser Pixel and server-side CAPI without a consistent deduplication strategy.

Use a stable event_id for the same customer action. The browser event and server event should use the same logical event identifier and matching event name so Meta can recognize them as the same conversion.

7. Access Tokens, Permissions and Reauthorization

Not every failed Make scenario is a payload problem. If your request used to work and suddenly stopped, check the connection before rebuilding the JSON.

Make’s current troubleshooting documentation specifically lists missing permissions and expired access-token/session problems as cases where you should restore permissions and reauthorize the connection.

8. Test the Event Before Touching Production

The fastest route out of a CAPI debugging loop is to stop using real conversions as test cases.

Step 1 — Use Meta’s Test Events area

Open your data source in Meta Events Manager and use the server-side Test Events workflow. Meta provides a test_event_code that can be attached to the request for testing.

Step 2 — Send one event

Send one simple event first. Do not start with a complicated Purchase payload containing dozens of custom parameters.

Step 3 — Confirm the request is accepted

A successful CAPI request is commonly returned with a response containing an events_received count, a messages array and an fbtrace_id.

{
  "events_received": 1,
  "messages": [],
  "fbtrace_id": "ABC123..."
}

Step 4 — Remove the test code for production

Once the test has been confirmed, remove the test-only parameter before switching the scenario to normal production traffic.

9. Do You Actually Need Make.com for Facebook CAPI?

This is an important 2026 question. Meta now offers a simplified one-click web Conversions API setup for eligible advertisers.

Make is particularly useful when you need:

• CRM → Meta conversion pipelines
• Stripe / payment → Meta Purchase events
• Webhook → enrichment → CAPI routing
• Meta + Google Ads + TikTok or other destinations from one event
• Custom filtering, branching and transformation logic
• Logging and retry workflows around failed events

10. Facebook CAPI 400 Error Troubleshooting Matrix

Five-minute debugging sequence

1. Read the entire Meta response. Copy the error message and code before changing anything.
2. Confirm the endpoint. Verify Graph API version, Pixel ID and request method.
3. Strip the request down. Test one simple valid event before adding optional fields.
4. Add matching data. Add hashed email, phone, fbp/fbc, custom data and event source URL as appropriate.
5. Add deduplication last. Confirm the browser and server paths share the correct event ID.

11. Production Checklist

Use this as the final QA pass before moving a Make.com CAPI scenario from testing into production.

Facebook CAPI 400 Bad Request FAQ

Official Meta & Make.com References

Related CreatorOpsMatrix Guides