DEV Community: Rahul Sharma

CF7 Form Submits Successfully But Nothing Appears in Airtable Here Is Why

Rahul Sharma — Fri, 10 Jul 2026 10:25:03 +0000

You set up a CF7 form, connected it to Airtable, and submitted a test entry. The form showed the success message. But when you opened your Airtable base, the record was nowhere to be found.

No error. No failed notification. Just silence.

This was posted on the WordPress support forums and it is one of the most common Airtable integration complaints. The form appears to work perfectly. Airtable receives nothing. Here are the reasons this happens and exactly how to fix each one.

Reason 1: The API Token Has Insufficient Scopes

Airtable moved from legacy API keys to Personal Access Tokens (PATs) in 2024. A PAT only has the permissions you explicitly grant it when you create it.

To write records to an Airtable base from an external integration, the token needs the data.records:write scope. Without it, the API call authenticates successfully but Airtable rejects the write operation. Your form submits. The plugin fires. The API call returns a 403 error that the plugin either logs silently or ignores entirely.

Go to airtable.com/create/tokens, open the token you are using, and confirm data.records:write is listed in the scopes. If it is not there, add it and save. Then test again.

Reason 2: The Base ID or Table Name Is Wrong

Airtable's API uses the base ID and table name to route your records to the correct location. Both have to be exactly right.

The base ID looks like appXXXXXXXXXXXXXX. It appears in the URL when you open the base in your browser. Do not use the base name. Use the ID.

The table name must match exactly what appears in Airtable, including capitalisation and spacing. If your table is called Contact Form Leads in Airtable, your integration must send that exact string. contact form leads or ContactFormLeads will not match and Airtable will return a 404 or route to nothing.

Reason 3: The Field Names in the Payload Do Not Match Airtable

Every record sent to Airtable contains field names and values. The field names in your API payload must exactly match the field names in your Airtable table.

If your Airtable table has a field called Full Name and your integration sends name or fullname, Airtable either creates an empty record (if required fields are missing) or ignores the value entirely.

The safest way to confirm your field names is to open your Airtable table, click on any field header, and note the exact name. Then check your integration's field mapping and make sure every name matches character for character.

Reason 4: The Plugin Is Catching a Silent Error

Some CF7 to Airtable plugins do not surface errors visibly when the API call fails. They fire the request, get a 401 or 403 back from Airtable, log nothing or log to a file nobody checks, and the form appears to succeed from the user's perspective.

Enable WordPress debug logging and submit a test form. Check wp-content/debug.log immediately afterward for any error from the Airtable API call. A 401 means authentication failed. A 403 means authenticated but not authorised. A 422 means the payload was received but failed validation.

Reason 5: CF7 Is Flagging the Submission as Spam

CF7 has a spam detection layer that runs before any integration fires. If the submission is caught by Akismet, CF7's honeypot, or a CAPTCHA that fired incorrectly, the form shows a success message but CF7 marks the submission internally as spam and does not fire the hooks that trigger Airtable integrations.

Submit the form with clearly non-spam data during testing. Temporarily disable Akismet if you have it active. If Airtable starts receiving records after disabling spam filtering, the submission was being flagged.

A More Reliable Way to Connect CF7 to Airtable

Dedicated CF7 to Airtable plugins handle the connection for you but give you limited visibility when things go wrong. When the record does not appear and there is no visible error, debugging is guesswork.

Contact Form to API connects CF7 directly to Airtable's REST API. You configure the Airtable endpoint URL, add your PAT as a Bearer Authorization header, and map your CF7 form fields to the exact Airtable field names your table uses. Every submission attempt logs the response from Airtable, so you see whether the record was created, and if not, you see the exact error Airtable returned. No guesswork about whether the token scope is right or whether the field name matched.

Checklist Before Debugging Further

Before spending more time on this, go through these quickly.

Confirm your PAT has data.records:write in its scopes.

Confirm the base ID in your integration starts with app and matches the URL of your Airtable base.

Confirm the table name in your integration matches exactly what appears in Airtable including capitalisation.

Confirm field names in the payload match field names in the table exactly.

Enable WP_DEBUG_LOG and check the log after a test submission for any API error response.

Temporarily disable Akismet and retest to rule out spam flagging.

CF7 Salesforce Integration Breaks After a WordPress Update - Here Is Why and How to Fix It

Rahul Sharma — Wed, 08 Jul 2026 11:25:35 +0000

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.

Random CF7 Submissions Not Reaching Google Sheets: The Causes Nobody Talks About

Rahul Sharma — Tue, 07 Jul 2026 10:13:27 +0000

A site owner posted on the WordPress forums with one of the most frustrating problems in CF7 integrations. Out of every 10 form submissions, 1 or 2 would silently disappear. Flamingo confirmed the form submitted successfully. No error appeared in debug.log. No error showed in the browser. The lead was just gone. Submitting the same form again moments later would work perfectly.

The plugin author suggested reauthenticating and promised an update. The thread was marked resolved. The problem was not actually resolved.

Random, intermittent failures with no error log are harder to diagnose than consistent failures. When something breaks every time, you can trace it. When it breaks 15% of the time for no apparent reason, the cause is almost always something outside the plugin itself.

Here are the four real reasons this happens.

Cause 1: Google Sheets API Rate Limiting

Google's Sheets API has rate limits. The free tier allows 100 read and write requests per 100 seconds per user. If your form receives bursts of traffic where multiple people submit within the same short window, you can hit this limit. When the limit is exceeded, Google returns a 429 error and the write is dropped.

The plugin in this thread had no retry logic at the time of the forum post. When Google returned a 429, the plugin received it, had nowhere to put it, logged nothing, and moved on. The submission sat in Flamingo but never reached Sheets.

You can verify this by checking your Google Cloud Console under APIs and Services, then Google Sheets API, then Quotas. If you see a spike in quota usage that correlates with your missing submissions, rate limiting is the cause.

The fix is either to implement exponential backoff retry logic (attempt the write again after 1 second, then 2, then 4) or to upgrade to a higher Google API quota if your volume justifies it. You can also switch to a service account instead of OAuth, which has separate quota tracking and often higher effective limits.

Cause 2: PHP Execution Timeout

The system info in the forum post showed Memory Limit: 40M and Time Limit: 90 seconds. The memory limit is low for a site running WP Rocket, multiple page builders, and several active plugins. The time limit is high, but it matters less than memory.

When a CF7 form submits, the plugin makes an outbound API call to Google. If the server is under load at that moment, this API call can be slow. If the PHP process runs out of memory before the API call completes, the process is killed mid-execution. The Google Sheets write never happens. The form submission itself had already been processed by CF7 (which is why Flamingo captured it), but the Google Sheets call that runs after it never finished.

This is random by nature because server load varies. Most submissions happen when the server has capacity. Occasional submissions happen during traffic spikes or resource-heavy background tasks, and those are the ones that fail.

Check your PHP error log for Allowed memory size exhausted errors. If you see them, increasing memory_limit in php.ini or .htaccess is the fix.

Cause 3: WP Rocket Caching the Form Submission

The system info in the forum post showed WP Rocket active. WP Rocket is a powerful caching plugin but it is known to interfere with certain AJAX-based form submissions if its settings are not configured correctly.

CF7 form submissions use AJAX. WP Rocket can cache AJAX responses, delay JavaScript execution, or defer scripts in a way that changes when CF7's submission handler fires. If the AJAX request that sends data to Google Sheets gets intercepted or delayed by WP Rocket's cache or script optimisation, the request can fire at the wrong time or not at all.

Check WP Rocket's settings under File Optimization and confirm that CF7's JavaScript files are excluded from deferral. The relevant file is contact-form-7/includes/js/index.js. Also check that the CF7 AJAX action (wpcf7_submit) is excluded from WP Rocket's AJAX caching.

The fact that the problem is intermittent and that resubmitting immediately works is consistent with a caching layer interfering. The first submission hits a cached response. The second submission hits the live server.

Cause 4: Google OAuth Token Expiry Mid-Session

As covered in another post about the invalid_grant error, Google OAuth tokens expire. If the token expires while your site is handling a submission, the API call to Google Sheets will fail silently if the plugin does not surface the error properly.

The intermittent nature fits this cause too. Tokens expire at a specific time. Submissions that arrive just after expiry fail. Submissions that arrive after the token has been refreshed succeed.

Check the plugin's settings for when OAuth was last authorised. If the Google Cloud Console OAuth app is in Testing status, tokens expire after 7 days. Set it to Production to get long-lived tokens.

The Reliable Alternative: Direct API Integration

All four causes above have one thing in common. They are amplified by having a middleware plugin manage the Google connection on your behalf. When the plugin mishandles a rate limit, fails to log an error, or loses a write during a resource spike, you have no visibility and no way to retry.

Contact Form to API calls the Google Sheets API directly using a service account Bearer token instead of OAuth. Service account tokens do not expire the same way OAuth tokens do, which removes cause 4 entirely. The direct API call also gives you full visibility into the response from every submission attempt, so a 429 rate limit response shows up in your logs rather than disappearing silently.

For high-volume forms, the direct API approach also makes it easier to implement your own retry logic around the Sheets write, which the dedicated plugin does not expose.

Diagnosing Which Cause You Are Hitting

Enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php if they are not already on. After your next missing submission, check wp-content/debug.log immediately for any memory, timeout, or API error entries.

Check your Google Cloud Console quotas dashboard for rate limit spikes around the times submissions went missing.

Temporarily disable WP Rocket's JavaScript optimisation and test again. If submissions stop going missing, WP Rocket is involved.

Check the last authorisation date in the GSheetConnector plugin settings and confirm your Google Cloud app is in Production status rather than Testing.

Why Your CF7 Google Sheets Connector Randomly Stops Working (And Re-Authorizing Doesn't Fix It)

Rahul Sharma — Fri, 03 Jul 2026 12:37:49 +0000

A WordPress support thread describes a pattern that shows up constantly with CF7-to-Google-Sheets connector plugins:

The connector works fine right after setup
Some time later, it just stops sending data
Deactivating and reactivating the plugin doesn't help
Revoking Google permissions and re-granting them doesn't help
Connecting to a brand new sheet from scratch has the same problem

The plugin author's own reply in that thread points people to check debug.log for authentication errors — which is the right instinct, because this almost never turns out to be a sheet permissions issue. It's an OAuth token lifecycle issue, and it's baked into how Google treats third-party apps that haven't gone through full verification.

The Actual Cause: Testing Mode and the 7-Day Token Expiry

Every plugin that connects to Google Sheets via OAuth does so through a Google Cloud project. That project has a publishing status: Testing or In Production. If the project is in Testing (which is the default, and where a lot of smaller plugin integrations stay), Google enforces a hard rule: refresh tokens issued to that app expire after exactly 7 days, regardless of how many times the user re-authorizes.

This explains the exact symptom in the thread. The connector works after setup because the token is fresh. A week or so later it silently dies. The site owner revokes and re-grants access, which issues a brand new token — so it works again for a few days, then dies again. Because the failure is intermittent and recovers temporarily after re-auth, it looks like a bug that "sometimes" happens rather than a fixed 7-day countdown.

A few related conditions produce the same invalid_grant failure and are worth ruling out too:

100-token cap — each Google account can hold at most 100 live refresh tokens per OAuth client. Past that, Google silently invalidates the oldest one with no warning
6-month inactivity — a refresh token that sits unused for six consecutive months is auto-revoked
Password change — if the connected scopes touch Gmail, a password reset revokes the token immediately
Workspace admin policy — an admin can restrict specific scopes after the fact, breaking a previously working connection

None of these are fixed by deactivating/reactivating the plugin, and none are fixed by connecting a new spreadsheet, since the token — not the sheet — is what's broken.

Why Re-Authorizing Doesn't Actually Fix It

Re-granting permission resets the clock, it doesn't remove the 7-day ceiling. As long as the underlying Google Cloud project stays in Testing mode, every token issued to it — old sheet or new sheet — will expire on the same schedule. Publishing the app to Production removes the 7-day limit, but for apps that use sensitive or restricted scopes, that requires completing Google's full OAuth verification process, which most small WordPress plugin setups never go through.

Sidestepping the Whole Problem

Contact Form to API doesn't authenticate to Google Sheets the way an OAuth connector does, which means the 7-day/100-token/6-month expiry rules that govern user-consent tokens don't apply at all. There are two ways to wire it up:

Option 1 — Google Apps Script Web App (fastest to set up)

Deploy a small Apps Script bound to your sheet as a Web App, set to "Execute as: Me" and "Anyone can access":

function doPost(e) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Sheet1');
  const data = JSON.parse(e.postData.contents);
  sheet.appendRow([new Date(), data.name, data.email, data.message]);
  return ContentService.createTextOutput(JSON.stringify({ status: 'ok' }))
    .setMimeType(ContentService.MimeType.JSON);
}

Authorization here happens once, at deployment time, under your own Google account — there's no separate per-request OAuth handshake and no refresh token to expire. Point Contact Form to API's request URL at the deployment's /exec URL, map your CF7 fields into the JSON body, and submissions land in the sheet directly.

Option 2 — Sheets API v4 with a service account (more robust)

If you'd rather call Google's real API instead of routing through Apps Script, create a service account in Google Cloud, share the target sheet with the service account's email, and authenticate requests with a JWT signed by the service account key:

POST https://sheets.googleapis.com/v4/spreadsheets/{spreadsheetId}/values/Sheet1!A1:append?valueInputOption=RAW
Authorization: Bearer {service_account_access_token}
Content-Type: application/json

{
  "values": [["2026-07-03", "Jane Doe", "jane@example.com", "Hello"]]
}

Service account credentials aren't part of the end-user consent lifecycle at all, so none of the Testing-mode expiry rules apply to them.

Troubleshooting Checklist

Check whether the connector's Google Cloud project is in Testing or Production status
If you have access to the project, check the refresh token count against the 100-token cap
Confirm the connected scopes don't include Gmail if a password was recently changed
If moving to a direct API/Apps Script approach, confirm the sheet is shared with the correct account (your own account for Apps Script, the service account email for the Sheets API)
Watch for invalid_grant specifically in logs — that error code, not a generic failure, confirms it's a token issue rather than a sheet permissions issue

If your CF7 integration keeps dying every week or so despite reconnecting, don't keep re-authorizing — check the publishing status of whatever Google Cloud project sits behind the connector, or skip the OAuth layer entirely with Contact Form to API.

CF7 + Sendinblue: Contacts Going to "All Contacts" Instead of Your Specific List

Rahul Sharma — Wed, 01 Jul 2026 08:10:16 +0000

A site owner posted on the WordPress forums with a problem that had been going on for months. Their CF7 form was connected to Sendinblue (now called Brevo) using CF7's built-in integration. Every time someone submitted the form, a new contact appeared in Sendinblue. But it always landed in the general "All Contacts" pool, never in the specific list they had selected in the plugin settings. The welcome email also never fired.

The CF7 plugin author said: "Necessary fields are missing in your form."

The site owner did not understand what that meant. Neither did a second person who replied months later with the exact same problem. The thread was closed with the issue unresolved for both of them.

This post explains what "necessary fields are missing" actually means, why the built-in integration behaves this way, and how to get contacts reliably into the right Sendinblue list every time.

What "Necessary Fields Are Missing" Actually Means

CF7's built-in Sendinblue integration has a step called Contact Attribute to Form-Field Mapping. This is where you tell CF7 which form field corresponds to which Sendinblue contact attribute.

The critical field is the email address. Even if your CF7 form has an email field, CF7's built-in Sendinblue integration does not automatically know that your email field should map to Sendinblue's EMAIL attribute. You have to map it explicitly in the integration settings.

Here is what happens when the email field is not mapped:

Sendinblue receives a contact creation request
Because no email attribute is explicitly provided in the mapped fields, Sendinblue creates a generic "identified contact" without a proper email
Without a valid email, Sendinblue cannot add the contact to a specific list — lists require identifiable contacts
The contact lands in the general pool instead of your desired list
The welcome email never fires because there is no valid email to send to

The fix for CF7's built-in integration is to go to CF7 Settings, open the Sendinblue tab, find the Contact Attribute to Form-Field Mapping section, and add a row that maps EMAIL to your form's email field name (e.g. your-email). Save the settings and test again.

Why This Keeps Tripping People Up

The CF7 Sendinblue integration UI has a separate section for selecting which list contacts should be added to. It is reasonable to assume that selecting a list there is all you need to do. The mapping step feels like optional customisation, not a required prerequisite for the list assignment to work.

But the list assignment depends on the contact having a valid, recognisable email. If the mapping is not set, the email is not in the payload in the way Sendinblue expects it, the contact is created without it, and the list assignment silently fails.

This is a documentation gap, not a bug. But the effect is the same: contacts go to the wrong place and the site owner has no visible error to diagnose.

The More Reliable Fix: Connect Directly to Brevo's API

CF7's built-in Sendinblue integration has multiple settings that have to be configured in exactly the right way before contacts land in the right list. If any one piece is missing, the whole thing silently fails.

A more direct approach is to call Brevo's API yourself with Contact Form to API. You send a POST request to Brevo's contacts endpoint and include the listIds array directly in the request body. There is no hidden mapping requirement. The list ID goes in the payload you control, so you always know exactly which list the contact will land in.

The Brevo API endpoint for this is:

POST https://api.brevo.com/v3/contacts

With a body like this:

{
  "email": "person@example.com",
  "attributes": {
    "FIRSTNAME": "Jane",
    "LASTNAME": "Smith"
  },
  "listIds": [5],
  "updateEnabled": true
}

The listIds array is where you put your Brevo list ID. The updateEnabled: true flag means existing contacts get updated rather than rejected, which avoids errors for repeat form submitters.

You find your list ID in Brevo under Contacts, Lists, and then opening the specific list. The ID appears in the URL.

What to Do If the Built-In Integration Fix Does Not Work

If you have added the email mapping and contacts are still landing in the wrong list, check these things.

Confirm your list ID in CF7's settings matches the actual list ID in Sendinblue. It is easy to copy the wrong number if you have multiple lists.

Check whether the Sendinblue list you selected requires double opt-in confirmation. If double opt-in is enabled on the list, contacts are placed in a pending state until they confirm their email. They will not appear in the list until they click the confirmation link in the email Sendinblue sends them.

Check whether the welcome email setting in CF7 is actually tied to a Sendinblue automation or transactional template. As covered in a related post, the welcome email checkbox in CF7's Sendinblue settings has unreliable behaviour and may not trigger a transactional template send.

Summary

Contacts landing in Sendinblue's general pool instead of your specific list almost always means the email field is not mapped in CF7's contact attribute mapping settings. The fix is to explicitly map EMAIL to your form's email field in the integration settings.

For a more reliable setup that gives you full control over which list receives the contact and exactly what data is sent, calling Brevo's contacts API directly through Contact Form to API removes the silent failure risk entirely.

CF7 Submissions Not Reaching Klaviyo? Here Is What Is Actually Going On

Rahul Sharma — Tue, 30 Jun 2026 08:09:54 +0000

A site owner posted on the WordPress forums that their signup form was not sending data to Klaviyo. The API key was correct. The list ID was correct. Everything looked set up properly, but submissions were not showing up.

The plugin author asked a clarifying question that turned out to be the key to the whole problem: did the form fail to submit with an error message, or did it submit successfully but the new contact never appeared in the Klaviyo list? Those are two completely different problems with two completely different fixes.

The site owner eventually found a setting that was wrong and fixed it themselves, but never said which one. This post covers every place a CF7 to Klaviyo integration can break, what each failure looks like, and how to fix it.

The First Thing to Check: List vs Campaign

This is the single most common confusion with Klaviyo integrations and it is worth ruling out before anything else.

When your CF7 form adds someone to Klaviyo, it only adds them to a list. It does not enroll them in a campaign. These are two separate things in Klaviyo. A list is a static collection of contacts. A campaign is an email that gets sent out, either immediately or on a schedule.

If you check your Klaviyo list and the new contact is sitting there correctly, your integration is working. If you were expecting them to receive an automatic welcome email and nothing arrived, that is a separate Klaviyo flow setup issue, not an integration issue. You need a Klaviyo flow that triggers when someone is added to that specific list, and that flow needs to be turned on. Check Klaviyo under Flows and confirm a "List Subscribed" trigger flow exists and is live, not in draft.

If the contact is not even appearing in the list at all, the problem is somewhere in the API call itself. Keep reading.

Reason 1: Using the Wrong Klaviyo API Version

Klaviyo has deprecated several older API endpoints over the past few years. If your integration was set up a while ago, or if a tutorial you followed was written before the changes, you might be using endpoints that no longer work the way you expect.

The old v1/v2 endpoints like POST /api/v2/list/{list_id}/subscribe are deprecated. If your plugin or custom code is still using them, the request can fail silently or return an error that your integration is not surfacing to you.

The current correct approach uses two separate API calls. First you create or update the profile:

POST https://a.klaviyo.com/api/profiles/

Then you add that profile to a list, or better yet, subscribe them with consent:

POST https://a.klaviyo.com/api/profile-subscription-bulk-create-jobs/

This second endpoint is what Klaviyo recommends if you want the contact's consent properly recorded, rather than just silently dropping them into a list with no marketing consent on record. If your form is a signup form meant for email campaigns, you want consent recorded correctly. Otherwise Klaviyo will treat the contact as not subscribed even though they appear in your list.

Reason 2: Authentication Header Format Is Wrong

Klaviyo's API requires the Authorization header in a very specific format:

Authorization: Klaviyo-API-Key pk_your_private_key_here

A common mistake is using Bearer instead of Klaviyo-API-Key:

Authorization: Bearer pk_your_private_key_here

This looks correct because Bearer is the standard format for most APIs, but Klaviyo specifically requires its own prefix. Using the wrong prefix returns a 401 authentication error. If your integration is silently failing and you have not checked the raw error response, this is one of the first things to verify.

You also need the API revision header on every request:

revision: 2024-10-15

Klaviyo versions its API by date. Missing this header can cause requests to behave unpredictably or get rejected depending on which default revision your account falls back to.

Reason 3: Missing Required Identifier on the Profile

Klaviyo requires at least one identifier to create a profile: an email address, a phone number, or an external ID. If your CF7 form only collects a phone number and your integration sends the request without an email and without marking the phone number correctly, Klaviyo returns:

{
  "detail": "One or more identifiers is required"
}

Check what fields your CF7 form actually sends to Klaviyo. If the form has an email field, make sure it is actually included in the payload and not accidentally left out of the field mapping.

Reason 4: Profile Already Exists (409 Conflict)

If someone has previously interacted with your Klaviyo account under the same email, trying to create them again as a brand new profile can return a 409 conflict:

{
  "detail": "A profile already exists with one of these identifiers"
}

This does not mean your integration is broken. It means Klaviyo already has a profile for that person somewhere in your account, even if they are not in the specific list you are checking. The correct behaviour is to update the existing profile rather than attempting to create a new one. Using the subscribe/bulk job endpoint mentioned above handles this correctly because it performs an upsert: it updates the profile if it exists, or creates it if it does not.

How to Set This Up Correctly Without Managing API Versions Yourself

Klaviyo's API has changed enough times that hand-rolled integrations or older plugins frequently break without obvious warning. The safest way to connect Contact Form 7 to Klaviyo reliably is to use a tool that calls Klaviyo's current API endpoints correctly and gives you visibility into what is actually being sent and received.

Contact Form to API lets you set up a Contact Form 7 to Klaviyo integration by configuring the exact Klaviyo endpoint, adding your API key with the correct Klaviyo-API-Key header format, and mapping your CF7 form fields to the profile attributes Klaviyo expects. You also get visibility into the response from each submission, so if something does fail, you see the actual error from Klaviyo instead of guessing why a contact never showed up.

This removes the guesswork around API versions, header formats, and consent handling that trips up most manual CF7 to Klaviyo setups.

Quick Checklist

If your CF7 form is not sending data to Klaviyo, work through these in order.

Check whether the contact actually appears in your Klaviyo list. If they do, your integration works and the issue is with a flow or campaign not being triggered, which is a separate Klaviyo setup task.

Confirm you are using current API endpoints, not the deprecated v1/v2 versions.

Check your Authorization header uses Klaviyo-API-Key, not Bearer.

Confirm your CF7 form sends at least one valid identifier (email, phone, or external ID) to Klaviyo.

If you see a 409 conflict error, switch to the subscribe/bulk job endpoint which performs an upsert instead of a strict create.

CF7 + Campaign Monitor: "Failed to Deserialize" 400 Error on Unchecked Checkbox

Rahul Sharma — Mon, 29 Jun 2026 08:55:57 +0000

A developer posted on the WordPress forums with a very specific and frustrating bug. Their CF7 form connected to Campaign Monitor worked perfectly when the newsletter checkbox was ticked. The moment someone left it unticked, the integration threw a 400 error:

{
  "Code": 400,
  "Message": "Failed to deserialize your request.\r\nPlease check the documentation and try again.\r\nFields in error: subscriber"
}

The plugin team fixed it in their next update. But the underlying reason this happens is worth understanding because the same bug will hit any CF7-to-Campaign Monitor integration that maps a checkbox to the "Authorized to send" field.

Why an Unchecked Checkbox Breaks the API Call

The CF7 form had a newsletter opt-in checkbox:

[checkbox add-to-nl use_label_element "accept newsletter"]

This was mapped to Campaign Monitor's Authorized to send field, which controls whether Campaign Monitor can send marketing emails to the subscriber.

When the checkbox is ticked, CF7 sends the value "accept newsletter" for the add-to-nl field. The integration plugin translates this to true and Campaign Monitor accepts it.

When the checkbox is left unticked, CF7 sends nothing for add-to-nl. There is no value because the user did not select anything. The integration plugin then either sends null, an empty string, or skips the field entirely.

Campaign Monitor's Authorized to send field expects a boolean: true or false. It cannot accept null, empty string, or a missing value. When it receives anything other than a proper boolean, it cannot parse the request and returns the deserialization error.

This is not a CF7 bug and it is not a Campaign Monitor bug. It is a gap in how the integration plugin handled the empty checkbox case. A ticked checkbox means true. An unticked checkbox means false. The plugin needed to explicitly convert the empty value to false before sending it to Campaign Monitor.

The Fix: Always Send a Boolean, Never Send Empty

The correct behaviour for any integration mapping a CF7 checkbox to a Campaign Monitor boolean field is to evaluate the checkbox state and send true or false explicitly.

If you are writing a custom integration, here is how to handle it:

add_action('wpcf7_before_send_mail', 'cf7_to_campaign_monitor');

function cf7_to_campaign_monitor($contact_form) {
    if ((int) $contact_form->id() !== YOUR_FORM_ID) return;

    $submission = WPCF7_Submission::get_instance();
    if (!$submission) return;

    $data = $submission->get_posted_data();

    // Checkbox returns an array of selected values when ticked,
    // or an empty array when unticked
    $newsletter_checked = !empty($data['add-to-nl']);

    $api_key  = defined('CM_API_KEY') ? CM_API_KEY : '';
    $list_id  = defined('CM_LIST_ID') ? CM_LIST_ID : '';

    $response = wp_remote_post(
        "https://api.createsend.com/api/v3.3/subscribers/{$list_id}.json",
        [
            'headers' => [
                'Authorization' => 'Basic ' . base64_encode($api_key . ':x'),
                'Content-Type'  => 'application/json',
            ],
            'body' => wp_json_encode([
                'EmailAddress'   => sanitize_email($data['your-email'] ?? ''),
                'Name'           => sanitize_text_field($data['your-name'] ?? ''),
                'ConsentToTrack' => $newsletter_checked ? 'yes' : 'no',
                'CustomFields'   => [
                    [
                        'Key'   => 'Activity',
                        'Value' => sanitize_text_field($data['activity'] ?? ''),
                    ],
                ],
                'Resubscribe' => true,
            ]),
            'timeout' => 15,
        ]
    );

    if (is_wp_error($response)) {
        error_log('[CF7->CM] Error: ' . $response->get_error_message());
    }
}

The key line is:

'ConsentToTrack' => $newsletter_checked ? 'yes' : 'no',

Whether the checkbox is ticked or not, Campaign Monitor always receives a valid value. Empty is never sent.

Note that Campaign Monitor's field name for this is ConsentToTrack in the API, not Authorized to send which is the label shown in the Campaign Monitor UI.

The Same Problem Affects Any Boolean Field

The deserialization error on an unchecked checkbox is not specific to Authorized to send. It will happen on any Campaign Monitor field that expects a boolean or a specific set of allowed values when the integration sends an empty or null value instead.

Common situations where this occurs:

A checkbox mapped to any Campaign Monitor custom field with a predefined set of options
An acceptance field mapped to consent or tracking fields
A dropdown that was left at the default empty option

In all these cases the fix is the same: evaluate the empty state explicitly and send the correct fallback value rather than sending nothing.

If You Are Using an Integration Plugin

If you are using Bit Integrations or any similar CF7-to-Campaign Monitor plugin and you are seeing this error, the first thing to do is update the plugin to the latest version. The Bit Integrations team confirmed they fixed this in an update released shortly after the forum thread.

If updating does not fix it, check your field mapping screen and look at how the checkbox field is mapped. Some plugins let you set a fallback value for when a checkbox is unchecked. Setting that fallback to false or no depending on what Campaign Monitor expects for that field will resolve the error.

If your plugin does not support fallback values for empty fields, that is a capability gap and switching to a more flexible integration tool is the right move. With Contact Form to API, you can set the Authorized to send field as a fixed value of no in the field mapping instead of mapping it to the CF7 checkbox directly. Campaign Monitor then always receives a valid boolean regardless of whether the visitor ticks the checkbox or not, which eliminates the deserialization error entirely.

Quick Summary

Scenario	What is sent to Campaign Monitor	Result
Checkbox ticked	`true` or `"yes"`	Success
Checkbox unticked, no fallback	`null` or empty string	400 deserialization error
Checkbox unticked, fallback set	`false` or `"no"`	Success

The fix is always in the fallback. Campaign Monitor needs a boolean. Empty is not a boolean. Always send one or the other.

CF7 + ActiveCampaign: Why the "Account" Field Never Shows in Your Field Mapper

Rahul Sharma — Thu, 25 Jun 2026 08:18:57 +0000

A developer posted on the WordPress support forums that their CF7 to ActiveCampaign integration was missing the "Account" field in the mapping section. They could see the Account field clearly in their ActiveCampaign account. It just never appeared in the plugin's field mapper.

The plugin team said it was under development and would be released next week. The developer waited five weeks. Then posted again. The field was still missing. The thread was closed.

This is not a bug that will be fixed by waiting for a plugin update. The reason the Account field is missing from CF7 integration mappers is a fundamental difference in how ActiveCampaign structures its data.

Why the Account Field Is Different From Other Fields

In ActiveCampaign, a Contact and an Account are two separate types of records.

A Contact is a person: name, email, phone, custom contact fields. When your CF7 form submits and the plugin calls ActiveCampaign's API, it calls the Contacts endpoint and creates or updates a person record.

An Account in ActiveCampaign is a company record. It has its own fields: company name, website, industry, annual revenue. Contacts can be linked to Accounts, but an Account is not a field on a Contact. It is a separate object with its own API endpoint.

This is why the Account field does not appear in the field mapper. The plugin fetches the list of available fields from ActiveCampaign's Contact fields API. The Account field is not in that list because it is not a Contact field. It belongs to a different API endpoint entirely.

Most CF7 to ActiveCampaign integration plugins only work with the Contacts endpoint. They were not built to create or link Account records, which is a separate operation.

What the ActiveCampaign API Actually Requires

To create a Contact and link it to an Account in ActiveCampaign, you need two API calls.

The first call creates or updates the Contact:

POST https://youraccountname.api-us1.com/api/3/contacts

The second call links that Contact to an Account:

POST https://youraccountname.api-us1.com/api/3/accountContacts

The second call takes the Contact ID returned from the first call and the Account ID from ActiveCampaign. It creates the relationship between the two records.

If the Account does not exist yet, you first need to create it:

POST https://youraccountname.api-us1.com/api/3/accounts

This is three API calls chained together, with IDs being passed from one response into the next request. That is a multi-step flow that most basic CF7 integration plugins were never designed to handle.

How to Actually Send Company Name to ActiveCampaign From CF7

There are two practical approaches depending on your situation.

The first approach is to store the company name as a custom Contact field in ActiveCampaign rather than as an Account. In your ActiveCampaign account, go to Settings then Custom Fields and create a new field called "Company" on the Contact object. This field will appear in your plugin's field mapper because it is a Contact field. Your CF7 form can map the company name field to it and it will be stored on the Contact record.

The downside is that this is not a proper ActiveCampaign Account record. It is just a text field on the Contact. If your team needs to use ActiveCampaign's Account features like account-level automation or company scoring, this workaround will not satisfy that requirement.

The second approach is to use a direct API integration that supports multi-step calls. Contact Form to API gives you control over the exact API endpoint and payload structure. You can configure it to call the ActiveCampaign Contacts endpoint with the person's details from your form. For the Account linking step, the Pro version supports chained API calls where the response from the first call is used in the second call.

The Faster Workaround: Use ActiveCampaign's Webhook Instead

If you need Account data in ActiveCampaign from CF7 submissions and do not want to build a custom PHP solution, you can use ActiveCampaign's own automation features as the middle layer.

Set up your CF7 integration to create the Contact record with whatever fields your plugin supports. Then create an ActiveCampaign automation that triggers when a new Contact is created. The automation can look up or create an Account based on the company name field you stored on the Contact, then link the Contact to that Account.

This pushes the Account logic into ActiveCampaign's automation engine where it belongs, and keeps your CF7 integration simple.

If You Need to Write This in PHP

For developers who want to own the full integration, here is the sequence of API calls:

add_action('wpcf7_before_send_mail', 'cf7_to_activecampaign_with_account');

function cf7_to_activecampaign_with_account($contact_form) {
    if ((int) $contact_form->id() !== YOUR_FORM_ID) return;

    $submission = WPCF7_Submission::get_instance();
    if (!$submission) return;

    $data    = $submission->get_posted_data();
    $api_key = defined('AC_API_KEY') ? AC_API_KEY : '';
    $api_url = defined('AC_API_URL') ? AC_API_URL : ''; // e.g. https://yourname.api-us1.com/api/3

    $headers = [
        'Api-Token'    => $api_key,
        'Content-Type' => 'application/json',
    ];

    // Step 1: Create or update the Contact
    $contact_res = wp_remote_post("$api_url/contacts", [
        'headers' => $headers,
        'body'    => wp_json_encode([
            'contact' => [
                'email'     => sanitize_email($data['your-email'] ?? ''),
                'firstName' => sanitize_text_field($data['your-firstname'] ?? ''),
                'lastName'  => sanitize_text_field($data['your-lastname'] ?? ''),
                'phone'     => sanitize_text_field($data['your-phone'] ?? ''),
            ],
        ]),
        'timeout' => 15,
    ]);

    $contact_body = json_decode(wp_remote_retrieve_body($contact_res), true);
    $contact_id   = $contact_body['contact']['id'] ?? null;
    if (!$contact_id) return;

    // Step 2: Create the Account (or find existing by name)
    $account_res = wp_remote_post("$api_url/accounts", [
        'headers' => $headers,
        'body'    => wp_json_encode([
            'account' => [
                'name' => sanitize_text_field($data['your-company'] ?? ''),
            ],
        ]),
        'timeout' => 15,
    ]);

    $account_body = json_decode(wp_remote_retrieve_body($account_res), true);
    $account_id   = $account_body['account']['id'] ?? null;
    if (!$account_id) return;

    // Step 3: Link the Contact to the Account
    wp_remote_post("$api_url/accountContacts", [
        'headers' => $headers,
        'body'    => wp_json_encode([
            'accountContact' => [
                'contact' => $contact_id,
                'account' => $account_id,
            ],
        ]),
        'timeout' => 15,
    ]);
}

Store credentials in wp-config.php:

define('AC_API_KEY', 'your-activecampaign-api-key');
define('AC_API_URL', 'https://youraccountname.api-us1.com/api/3');

Summary

The Account field is missing from CF7 integration mappers because it is not a Contact field in ActiveCampaign. It lives on a separate Account object that requires its own API endpoint and a separate API call to link to a Contact. Most CF7 plugins only map to Contact fields. The solutions are to store company name as a custom Contact field, use ActiveCampaign automations to handle the Account linking, or use a direct API integration that supports multi-step calls.

CF7 to Airtable: Tables and Databases Not Loading in the Mapping Screen

Rahul Sharma — Wed, 24 Jun 2026 08:04:38 +0000

You installed the CF7 to Airtable plugin, generated a token from your Airtable account, pasted it into the plugin settings, and now you are staring at an empty dropdown where your bases and tables should appear. The plugin says it connected but nothing loads.

This is exactly what one developer experienced and posted on the WordPress support forums. The fix was simple once the plugin author looked at the screenshots: the token was too short. It was either truncated when it was copied or the wrong type of token was used.

But there is more to this problem than just copy-paste errors. This post covers the full picture so you get your CF7 to Airtable integration working correctly the first time.

The Token Type Problem: Legacy API Key vs Personal Access Token

Airtable deprecated their legacy API keys in early 2024. If you have used Airtable for a while and have an old connection somewhere, you might have a legacy API key that looks like this:

keyXXXXXXXXXXXXXX

That format no longer works. Airtable now uses Personal Access Tokens (PATs). A correctly formatted PAT looks like this:

patXXXXXXXXXXXXXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

It starts with pat, has a 17-character identifier, a dot, and then a long 64-character string. The full token is much longer than the legacy API key. If the token you pasted into the plugin is short or does not start with pat, that is why your tables are not loading.

The Scope Problem: Token Has No Permission to Read Bases

Even with a correctly formatted PAT, your tables will still not appear if the token does not have the right scopes assigned to it.

When you create a Personal Access Token in Airtable, you choose which permissions it has. The minimum scopes needed for a CF7 plugin to list your bases and tables are:

data.records:write so it can create new records from form submissions
schema.bases:read so it can read the list of your bases and tables

If schema.bases:read is missing, the plugin authenticates successfully but when it tries to fetch the list of your bases to populate the dropdown, Airtable returns an empty or forbidden response. From the plugin's side it looks like there are no bases. From your side it looks like the integration is broken.

Go back to your Airtable token settings at airtable.com/create/tokens, find the token you are using, and check which scopes are assigned. Add schema.bases:read if it is missing.

The Access Problem: Token Cannot See the Right Bases

The third reason tables do not load is that the token's access is not set to include the base you want to use.

When creating a PAT, you choose which bases it can access. You can set it to "All current and future bases" or restrict it to specific bases. If you restricted it and the base you want to connect to was not included, the plugin will not be able to see it.

Check the access settings on your token and make sure the base you want appears in the list, or change the access to "All bases" if you want the plugin to show everything.

How to Generate a Token That Actually Works

Go to airtable.com/create/tokens and create a new token. Give it a descriptive name like "WordPress CF7 Integration" so you can find it easily later.

Under Scopes, add at minimum:

data.records:write
schema.bases:read

Under Access, either select "All current and future bases" or choose the specific base your CF7 form should write to.

Click Create Token and copy the full token immediately. Airtable only shows you the complete token once. If you close the screen without copying it, you will need to regenerate it. The token starts with pat and is quite long. Copy all of it.

Paste the complete token into the plugin settings. If the bases and tables now appear in the dropdown, the token is working correctly.

Testing the Token Before Connecting the Plugin

If you want to confirm your token is valid before touching the plugin settings, you can test it with a quick API call. Open your browser's address bar or use any API testing tool and call:

GET https://api.airtable.com/v0/meta/bases
Authorization: Bearer YOUR_PAT_TOKEN

If the token is valid and has the right scopes, you get back a JSON object listing your bases with their IDs and names. If you get a 401 or 403 response, the token has an issue with either its validity or its scopes.

The Alternative: Connect CF7 Directly to Airtable's API

Dedicated CF7 to Airtable plugins require a specific token format and scope setup that varies by plugin version and Airtable API changes. When Airtable updates something, the plugin may stop working until it is updated too.

Contact Form to API connects CF7 directly to Airtable's REST API endpoint. You configure the specific Airtable base URL, add your PAT as a Bearer authorization header, and map your CF7 fields to the Airtable column names. Because you are calling the API directly with the exact endpoint and field names, there is no middleware layer that can break when Airtable changes their token format.

Quick Checklist

If your tables are not loading in the CF7 Airtable plugin:

Check that your token starts with pat and is the full length. A short token or one starting with key will not work.

Check the token scopes include schema.bases:read and data.records:write.

Check the token access includes the base you want to use.

Regenerate the token if you are unsure whether you copied it completely the first time.

Test the token directly against api.airtable.com/v0/meta/bases to confirm it works before blaming the plugin

CF7 Brevo Integration Adds Contacts But Never Sends the Welcome Email - Here Is Why

Rahul Sharma — Mon, 22 Jun 2026 08:20:50 +0000

A site owner posted on the WordPress support forums with a problem that was driving them crazy. Their CF7 form was connected to Brevo using CF7's built-in integration. Contacts were being added to the Brevo list perfectly after every form submission. But the welcome email was never being sent. Brevo support confirmed they were receiving no email send request at all from the website.

The CF7 plugin author suggested deactivating all plugins and switching to the default theme. On a live production site, that is not a realistic option. The thread was left unresolved.

The real reason this happens has nothing to do with plugin conflicts. It is a gap in what CF7's built-in Brevo integration actually does.

What CF7's Built-In Brevo Integration Actually Does

CF7 added native Brevo integration as a built-in feature. When you configure it and a form is submitted, CF7 makes an API call to Brevo to add the contact to your selected list.

That API call goes to Brevo's contacts endpoint:

POST https://api.brevo.com/v3/contacts

This call creates or updates the contact in your Brevo account and adds them to the specified list. It works. The site owner confirmed contacts were appearing in Brevo correctly.

But sending a welcome email using a transactional template is a completely different operation. It requires a separate API call to Brevo's transactional email endpoint:

POST https://api.brevo.com/v3/smtp/email

This second call does not happen. CF7's built-in Brevo integration only makes the contacts call. It does not make the transactional email call. There is no bug here. It is simply a feature that the built-in integration does not include.

Why the Welcome Email Option Exists But Does Not Work

CF7's Brevo settings panel includes a "Send a welcome email" checkbox. The existence of this option implies that checking it will send the welcome email. But based on Brevo's own confirmation that no email send request is reaching their servers, this option either does not trigger the transactional email API call or only works under specific conditions that are not documented.

The most likely explanation is that this setting was intended to work alongside Brevo's double opt-in confirmation email feature, not with a custom transactional template. Brevo has a built-in confirmation email mechanism tied to lists, which is separate from sending a transactional template with a specific template ID. The checkbox in CF7 may only activate the Brevo list-level confirmation email, not a custom template send.

How to Actually Send a Welcome Email After CF7 Submission

To send a welcome email using a specific Brevo transactional template after a CF7 submission, you need to make the second API call yourself. The cleanest way to do this is with a PHP function that hooks into CF7's submission event.

add_action('wpcf7_before_send_mail', 'send_brevo_welcome_email');

function send_brevo_welcome_email($contact_form) {
    if ((int) $contact_form->id() !== YOUR_FORM_ID) return;

    $submission = WPCF7_Submission::get_instance();
    if (!$submission) return;

    $data  = $submission->get_posted_data();
    $email = sanitize_email($data['your-email'] ?? '');
    $name  = sanitize_text_field($data['your-name'] ?? '');

    if (empty($email)) return;

    $api_key     = defined('BREVO_API_KEY') ? BREVO_API_KEY : '';
    $template_id = 12; // replace with your Brevo template ID

    $response = wp_remote_post('https://api.brevo.com/v3/smtp/email', [
        'headers' => [
            'api-key'      => $api_key,
            'Content-Type' => 'application/json',
        ],
        'body' => wp_json_encode([
            'templateId' => $template_id,
            'to'         => [['email' => $email, 'name' => $name]],
            'params'     => [
                'FIRSTNAME' => $name,
            ],
        ]),
        'timeout' => 15,
    ]);

    if (is_wp_error($response)) {
        error_log('[CF7->Brevo] Welcome email failed: ' . $response->get_error_message());
    }
}

Add your API key to wp-config.php:

define('BREVO_API_KEY', 'your-brevo-api-key-here');

Your template ID is the number that appears in Brevo under Email Templates when you open the template you want to use.

The params object lets you pass personalisation variables into your Brevo template. If your template uses {{ params.FIRSTNAME }}, the value you pass in params.FIRSTNAME will be substituted in.

The No-Code Option

If you do not want to manage PHP code, Contact Form to API lets you connect CF7 directly to Brevo's transactional email endpoint from the WordPress dashboard. You set the API endpoint, add your Brevo API key as the api-key header, configure the JSON body with your template ID and the CF7 fields mapped to the to and params values, and the welcome email fires automatically on every form submission.

This gives you the same result as the custom PHP approach without writing or maintaining any code. And because it calls the transactional email endpoint directly, you know the welcome email request is actually being sent to Brevo rather than silently not firing.

Quick Check: Is Your Template Actually Active?

Before assuming the integration is the problem, confirm one thing in Brevo. Go to Email Templates and open the template you want to use. Check that the status shows as Active. Brevo will not send emails for draft or inactive templates even if the API call reaches them. The site owner in the forum confirmed their template was active, but this is the first thing to verify if you are debugging this issue yourself.

Summary

CF7's built-in Brevo integration adds contacts successfully but does not make the separate API call needed to send a transactional welcome email. The "Send a welcome email" checkbox in CF7's settings does not trigger a transactional template send. To actually send a Brevo welcome email on CF7 form submission, you need either a custom PHP function that calls POST /v3/smtp/email or a plugin like Contact Form to API that handles that call from a configuration interface.

CF7 to CleverReach Integration Errors: What Each One Means and How to Fix It

Rahul Sharma — Fri, 19 Jun 2026 10:10:12 +0000

A site owner posted on the WordPress forums that their CF7 to CleverReach integration had been throwing errors for a week. The logs looked scary. The plugin author said the spam-related errors could be ignored. Thread closed.

That answer is only partly right. The logs in this thread actually contain three completely different types of errors, each with a different cause and a different fix. If you are seeing similar errors in your CF7 to CleverReach setup, here is what each one actually means.

Error 1: `invalid_grant` on the OAuth Token Endpoint

POST https://rest.cleverreach.com/oauth/token.php
400 Bad Request
{"error":"invalid_grant","error_description":"Authorization code doesn't exist or is invalid for the client"}

This is the most important error in the log and the only one that is genuinely a problem with your integration. It means the OAuth authorization code your plugin used to connect to CleverReach has expired or been invalidated.

When you first connect the CF7 CleverReach plugin to your account, CleverReach issues an authorization code. That code is exchanged for an access token and a refresh token. If something invalidates those tokens, the plugin can no longer authenticate and every attempt to refresh fails with invalid_grant.

This happens when you change your CleverReach password, when you revoke the app's access in your CleverReach account settings, or when the authorization code expires before the plugin could exchange it. It can also happen if you migrated your WordPress site to a new server and the stored tokens did not transfer correctly.

The fix is to disconnect the plugin from CleverReach and reconnect it from scratch. Go to the plugin settings, revoke the current connection, and go through the authorization flow again. This gives you a fresh set of tokens and clears the invalid_grant error.

Error 2: `403 Forbidden: email not allowed`

POST https://rest.cleverreach.com/v2/forms.json/239438/send/activate
403 Forbidden
{"error":{"code":403,"message":"Forbidden: email not allowed"}}

This error appears dozens of times in the log. The plugin author said to ignore it because CleverReach rejects known spam emails. That is accurate but there is more to understand here.

CleverReach maintains a blocklist of email addresses and domains that have been flagged as spam sources, disposable inboxes, or previously bounced addresses. When your CF7 form receives a submission from one of these addresses, CleverReach refuses to add it to your list. That is actually CleverReach protecting your sender reputation, not something going wrong with your integration.

Looking at the actual email addresses in the log, some are clearly spam bot submissions. The field values for several of these entries contain Telegram phishing links and promotional spam text in what should be a name field. These are not real people filling in your form. They are bots.

So the 403 email not allowed errors are doing you a favour. CleverReach is rejecting spam bot submissions that should never have reached your email list in the first place. You do not need to fix this error. You need to stop the spam bots from submitting your form so they never hit the CleverReach API at all.

Adding a honeypot field or enabling Cloudflare Turnstile on your CF7 form stops most bots before they submit. CF7 has a built-in honeypot option that bots fill in but real users cannot see, and CF7 rejects any submission where that field has a value.

Error 3: `400 Bad Request: duplicate address`

POST https://rest.cleverreach.com/v2/groups.json/1173358/receivers
400 Bad Request
{"error":{"code":400,"message":"Bad Request: \"duplicate address 'ackstein01@aol.com'\""}}

This error means someone tried to sign up with an email address that already exists in your CleverReach group. This is not a bug and it is not something you need to fix. CleverReach prevents duplicate email addresses in the same group.

If you want to update an existing contact's details when they submit your form again, you need to use CleverReach's update endpoint rather than the add endpoint. Most CF7 integration plugins use the add endpoint by default and do not handle duplicates.

The Real Problem: Your Form Has No Spam Protection

The most revealing thing in this log is what the spam bot submissions look like. Fields that should contain a person's name contain Telegram links and cryptocurrency scam text. This means your CF7 form is completely unprotected and bots are submitting it freely.

Every spam submission that reaches CleverReach uses one of your API calls and potentially triggers a 403 error in your logs. More importantly, if a bot ever submits with a real-looking email address that CleverReach does not recognise as spam, that address gets added to your marketing list without that person's consent.

Fixing your spam problem protects your CleverReach list quality, reduces unnecessary API calls, and clears most of the errors from your log. The best options are CF7's built-in honeypot, Google reCAPTCHA, or Cloudflare Turnstile, all of which CF7 supports natively.

A More Reliable Way to Connect CF7 to CleverReach

The dedicated CF7 CleverReach plugin works for many people but it has limitations. It relies on an OAuth connection that can break when credentials change, it does not handle duplicate contacts gracefully, and it gives you limited control over which fields are sent and how.

Contact Form to API connects CF7 directly to CleverReach's REST API using a straightforward API key instead of OAuth. API keys do not expire the way OAuth tokens do, so you do not get invalid_grant errors weeks after setting up the integration. You also get full control over the field mapping, which means you can send exactly the data CleverReach expects and avoid payload issues.

Quick Summary

Error	What it means	What to do
`invalid_grant`	OAuth tokens expired or revoked	Disconnect and reconnect the plugin in settings
`403 email not allowed`	CleverReach blocked a spam or invalid email	Add spam protection to your CF7 form
`400 duplicate address`	Email already exists in CleverReach group	Normal behaviour, or switch to an update endpoint

CF7 Webhook Getting a 400 Bad Request? The Problem Is Probably Not JSON Encoding

Rahul Sharma — Thu, 18 Jun 2026 12:30:47 +0000

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.

DEV Community: Rahul Sharma

CF7 Form Submits Successfully But Nothing Appears in Airtable Here Is Why

Reason 1: The API Token Has Insufficient Scopes

Reason 2: The Base ID or Table Name Is Wrong

Reason 3: The Field Names in the Payload Do Not Match Airtable

Reason 4: The Plugin Is Catching a Silent Error

Reason 5: CF7 Is Flagging the Submission as Spam

A More Reliable Way to Connect CF7 to Airtable

Checklist Before Debugging Further

CF7 Salesforce Integration Breaks After a WordPress Update - Here Is Why and How to Fix It

What "POST requires content-length" Actually Means

Why Field Mapping Breaks Silently

How to Verify Your Field Mapping After Any Plugin Update

The Longer-Term Problem: Integration Fragility

Salesforce Required Fields That Must Always Be Mapped

Checklist After Any WordPress or Plugin Update

Random CF7 Submissions Not Reaching Google Sheets: The Causes Nobody Talks About

Cause 1: Google Sheets API Rate Limiting

Cause 2: PHP Execution Timeout

Cause 3: WP Rocket Caching the Form Submission

Cause 4: Google OAuth Token Expiry Mid-Session

The Reliable Alternative: Direct API Integration

Diagnosing Which Cause You Are Hitting

Why Your CF7 Google Sheets Connector Randomly Stops Working (And Re-Authorizing Doesn't Fix It)

The Actual Cause: Testing Mode and the 7-Day Token Expiry

Why Re-Authorizing Doesn't Actually Fix It

Sidestepping the Whole Problem

Troubleshooting Checklist

CF7 + Sendinblue: Contacts Going to "All Contacts" Instead of Your Specific List

What "Necessary Fields Are Missing" Actually Means

Why This Keeps Tripping People Up

The More Reliable Fix: Connect Directly to Brevo's API

What to Do If the Built-In Integration Fix Does Not Work

Summary

CF7 Submissions Not Reaching Klaviyo? Here Is What Is Actually Going On

The First Thing to Check: List vs Campaign

Reason 1: Using the Wrong Klaviyo API Version

Reason 2: Authentication Header Format Is Wrong

Reason 3: Missing Required Identifier on the Profile

Reason 4: Profile Already Exists (409 Conflict)

How to Set This Up Correctly Without Managing API Versions Yourself

Quick Checklist

CF7 + Campaign Monitor: "Failed to Deserialize" 400 Error on Unchecked Checkbox

Why an Unchecked Checkbox Breaks the API Call

The Fix: Always Send a Boolean, Never Send Empty

The Same Problem Affects Any Boolean Field

If You Are Using an Integration Plugin

Quick Summary

CF7 + ActiveCampaign: Why the "Account" Field Never Shows in Your Field Mapper

Why the Account Field Is Different From Other Fields

What the ActiveCampaign API Actually Requires

How to Actually Send Company Name to ActiveCampaign From CF7

The Faster Workaround: Use ActiveCampaign's Webhook Instead

If You Need to Write This in PHP

Summary

CF7 to Airtable: Tables and Databases Not Loading in the Mapping Screen

The Token Type Problem: Legacy API Key vs Personal Access Token

The Scope Problem: Token Has No Permission to Read Bases

The Access Problem: Token Cannot See the Right Bases

How to Generate a Token That Actually Works

Testing the Token Before Connecting the Plugin

The Alternative: Connect CF7 Directly to Airtable's API

Quick Checklist

CF7 Brevo Integration Adds Contacts But Never Sends the Welcome Email - Here Is Why

What CF7's Built-In Brevo Integration Actually Does

Why the Welcome Email Option Exists But Does Not Work

How to Actually Send a Welcome Email After CF7 Submission

The No-Code Option

Quick Check: Is Your Template Actually Active?

Summary

CF7 to CleverReach Integration Errors: What Each One Means and How to Fix It

Error 1: invalid_grant on the OAuth Token Endpoint

Error 2: 403 Forbidden: email not allowed

Error 3: 400 Bad Request: duplicate address

The Real Problem: Your Form Has No Spam Protection

A More Reliable Way to Connect CF7 to CleverReach

Quick Summary

CF7 Webhook Getting a 400 Bad Request? The Problem Is Probably Not JSON Encoding

What the Debug Log Is Actually Showing You

The Actual Cause of "Field Cannot Be Empty" on a 400 Response

Error 1: `invalid_grant` on the OAuth Token Endpoint

Error 2: `403 Forbidden: email not allowed`

Error 3: `400 Bad Request: duplicate address`