A developer updated their client's WordPress site to 5.3.2 and updated the CF7 Salesforce plugin at the same time. Both updates completed without issue. But from that point on, no new records were being created in Salesforce. The Salesforce log showed this:
Data Sent: Nothing posted to Salesforce
Message: POST requires content-length
errorCode: UNKNOWN_EXCEPTION
The form itself was working fine. Flamingo showed every submission. Salesforce received nothing.
The plugin author said to check field mapping. The developer adjusted the mapping and it worked again. But neither the forum post nor the plugin author explained why a WordPress update would break a field mapping that was working perfectly before.
This post explains exactly what happened, what the error message actually means, and how to build a CF7 to Salesforce integration that does not break when WordPress updates.
What "POST requires content-length" Actually Means
The error POST requires content-length is a Salesforce API error, not a WordPress error. It means the HTTP request that arrived at Salesforce's endpoint had an empty or missing body. Salesforce expected a JSON payload with lead data and received nothing.
This does not happen because WordPress updated. WordPress updates do not change how form data is collected or how field mapping works. What actually happened is that the plugin update that ran at the same time reset or altered the field mapping configuration.
When a plugin updates, it can reset custom settings if the update involves schema changes to how settings are stored. The developer's field mapping was wiped or changed by the plugin update, not by the WordPress update. The form submitted successfully, the plugin tried to POST to Salesforce, sent an empty body because no fields were mapped, and Salesforce returned the content-length error.
Why Field Mapping Breaks Silently
The CF7 Salesforce plugin passes the form's submitted data to Salesforce based on the mapping you configure. Each CF7 field tag gets mapped to a Salesforce field name like FirstName, LastName, Email, Company.
When the mapping is correct, the plugin builds a JSON body like this:
{
"FirstName": "Jane",
"LastName": "Smith",
"Email": "jane@example.com",
"Company": "Acme Corp"
}
When the mapping is empty or broken, the plugin sends this:
{}
Salesforce receives an empty object. Its validation requires LastName at minimum for a Lead record. No LastName and no content in the body means the request fails with the content-length error. The plugin logs "Nothing posted to Salesforce" because the payload was genuinely empty.
The issue is that this fails silently from the user's perspective. The form shows success. Flamingo logs the submission. Nothing in the UI indicates that the Salesforce write produced an empty payload.
How to Verify Your Field Mapping After Any Plugin Update
After updating any CF7 CRM integration plugin, always open the plugin's field mapping settings and confirm your mappings are still in place before assuming the integration is working.
For the CF7 Salesforce plugin specifically, go to the form settings and open the Salesforce Feeds or Mapping section. Confirm every required Salesforce field (FirstName, LastName, Email, Company) has a CF7 form field mapped to it. Submit a test form and check the Salesforce log immediately for the status.
If the log shows a Salesforce ID being returned, the record was created. If it shows N/A with the content-length error, your mapping is empty.
The Longer-Term Problem: Integration Fragility
The real issue here is not a bug. It is fragility. A plugin update wiped a mapping configuration that was working correctly. The integration broke silently. Leads were lost until someone noticed.
This is a structural problem with dedicated CF7 CRM plugins that store your integration configuration in their own database schema. When they update that schema, existing configurations can be reset, altered, or orphaned.
Contact Form to API takes a different approach. Your integration is configured as a direct API request with an explicit JSON payload body. The field mapping lives in a request body you define, like this:
{
"FirstName": "[your-name]",
"LastName": "[last-name]",
"Email": "[your-email]",
"Company": "[your-subject]"
}
This mapping does not live in a proprietary database schema that can be reset by a plugin update. It is part of your integration configuration that you define and control. When you update the plugin, your payload definition stays intact. A 201 response in the API logs confirms every record was created successfully in Salesforce.
The Pro version with the OAuth Add-on handles Salesforce's OAuth 2.0 authentication flow directly from WordPress, connecting to Salesforce's Lead API at POST /services/data/v63.0/sobjects/Lead/ without any Zapier or middleware dependency.
Salesforce Required Fields That Must Always Be Mapped
Salesforce requires at minimum one field for a Lead record to be created. In practice you need at least LastName and Company. Without these, Salesforce returns a validation error regardless of whether the other fields are correct.
Make sure these are always in your mapping:
| CF7 Field | Salesforce API Field | Required |
|---|---|---|
| Name field | LastName |
Yes |
| Company field | Company |
Yes |
| Email field | Email |
Recommended |
| Phone field | Phone |
Optional |
If your CF7 form does not have separate first name and last name fields, map your full name field to LastName. Salesforce will accept it.
Checklist After Any WordPress or Plugin Update
Before trusting that your Salesforce integration survived an update, go through this list.
Open the field mapping settings in your CF7 Salesforce plugin and confirm all mappings are present.
Submit a test form with real-looking data, not just "test test@test.com."
Check the Salesforce log immediately and confirm a Salesforce ID was returned.
Log into Salesforce and search for the test contact you just submitted to confirm it actually appears as a Lead record.
If any step fails, check the mapping first before investigating anything else.
Top comments (0)