A developer posted on the WordPress forums with a detailed bug report. Their CF7 webhook was sending data to an external REST API and getting a 400 Bad Request response. The API was returning validation errors saying required fields were empty. They had checked the debug log, seen the request body wrapped in quotes, and concluded the plugin was double-encoding the JSON.
The plugin author explained that the debug log shows a string representation of the payload for logging purposes, not the actual bytes sent over the network. The JSON was never double-encoded.
The real problem was a wrong field name. The developer used _notify_leadtype_id but the API required leadtype_id. Because the field name was wrong, the API never received a value for that required field and rejected the whole request.
This is one of the most common reasons CF7 webhooks return 400 errors, and it is almost always misdiagnosed as an encoding issue. This post explains how to read webhook debug logs correctly and how to find the actual cause of 400 errors.
What the Debug Log Is Actually Showing You
When a CF7 webhook plugin sends a debug email after a failed request, the request body section looks something like this:
Request Body:
"{\n \"lead_type_id\": 318825,\n \"contact_name\": \"John Doe\"\n}"
The outer quotes and all those backslash characters make it look like the JSON has been double-encoded or stringified inside a string. It has not. This is just how a JSON string looks when it is printed as a PHP string for logging purposes. The backslashes are escape characters that PHP adds when displaying a string that contains quote marks.
The actual bytes sent to the API over the network look like this:
{
"lead_type_id": 318825,
"contact_name": "John Doe"
}
That is valid JSON. The API receives it correctly formatted. The debug log display is misleading but it is not evidence of a problem with the encoding.
If you see a 400 response with validation errors saying fields are empty, the encoding is almost certainly fine. Look at the field names instead.
The Actual Cause of "Field Cannot Be Empty" on a 400 Response
When an API returns a 400 with a message like this:
{
"code": 400,
"success": false,
"message": {
"validation": {
"leadtype_id": ["Field cannot be empty"]
}
}
}
It means the API received the request, parsed the JSON successfully, and then checked whether required fields were present. It found that leadtype_id was missing or null.
This happens for three reasons in CF7 webhook setups:
Wrong field name in your webhook body. You used _notify_leadtype_id but the API expects leadtype_id. The API ignores the field it does not recognise and treats the required field as empty. This was exactly the problem in the forum thread.
Field value is empty because the CF7 field was not filled in. If you are mapping a CF7 form field to the API and the user left that field blank, the API receives an empty string or null for a required field.
The value is a hardcoded static value that was not included correctly. The developer needed to send lead_type_id: 318825 as a fixed integer, not from a form field. If the webhook plugin does not support hardcoded static values in the request body, the field either gets sent as the placeholder text or not at all.
How to Find the Correct Field Names
Every API has documentation that lists the exact field names it expects. These are case-sensitive and exact. leadtype_id, lead_type_id, and LeadTypeId are all different field names that an API treats as completely different keys.
Before setting up a webhook, open the API documentation for the endpoint you are calling. Find the request body schema and write down the exact field names as they appear in the docs. Do not copy them from a code example or a forum post. Copy them from the official reference page for that specific endpoint.
For the RO App API in this thread, the correct documentation page was roapp.readme.io/reference/create-lead. The field there was leadtype_id, not _notify_leadtype_id. One character difference, completely silent failure.
Testing Your Field Names Before Connecting CF7
Before wiring up your CF7 form, test the API call directly with your exact field names and values. The fastest way is cURL from a terminal:
curl -X POST https://api.example.com/lead/ \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"leadtype_id": 318825,
"contact_name": "Test User",
"contact_phone": "123456789"
}'
If this returns a success response, your field names are correct and your credentials work. Then when you set up CF7, you know any problems are in the mapping, not in your understanding of the API.
If this returns a 400, the problem is in your request. Check the field names against the documentation one more time.
Sending Static Values Alongside Form Fields
The developer needed to send leadtype_id as a fixed number (not from a form field) alongside dynamic values like contact_name from the form. This is a common requirement when integrating with CRMs that need an internal category ID alongside the contact details.
Not all CF7 webhook plugins support mixing static values and dynamic form field values in the same request body. Some only support CF7 field placeholders.
Contact Form to API supports both. You can set some fields as static hardcoded values (like "leadtype_id": 318825) and map other fields dynamically from your CF7 form submission. The request body is built correctly and sent as a real JSON object to your API endpoint.
This is exactly the use case from the forum thread: a fixed lead type ID that never changes, combined with dynamic contact details from the form.
Quick Checklist When You Get a 400 Response
Work through these before assuming anything is wrong with the plugin:
First, check the field names in your webhook body against the API documentation. Copy and paste them directly from the official reference. Do not type them from memory.
Second, look at the validation errors in the response body. If the API tells you which field is empty or invalid, it is telling you exactly what to fix.
Third, test the API call directly with cURL or Postman using your exact payload. If it works there, the problem is in how your plugin is building the request.
Fourth, check whether your plugin supports static hardcoded values in the request body. If you need to send a fixed ID alongside form fields and the plugin does not support that, you will always get a missing field error.
