DEV Community: Rahul Sharma

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.

How to Connect Contact Form 7 to Monday.com CRM

Rahul Sharma — Wed, 17 Jun 2026 10:37:24 +0000

Someone asked on the WordPress support forums: "What is the best way to connect Contact Form 7 to Monday CRM? Is a webhook a good approach?"

The reply said it is not possible with CF7's built-in features alone and suggested finding a plugin or writing custom code.

That answer is accurate but leaves the person with no path forward. This post gives you the full picture - how Monday.com's API works, what a webhook approach actually involves, and the simplest way to get CF7 submissions into Monday.com without writing any code.

Why CF7 Does Not Connect to Monday.com Out of the Box

Contact Form 7 is a form builder. It handles displaying your form, validating the fields, and sending you an email when someone submits. It was not built to push data to external services.

Connecting CF7 to Monday.com requires something in the middle that catches the form submission and sends it to Monday's API. That something is either a plugin, a webhook handler, or custom PHP code.

The good news is that Monday.com has a well-documented API and the connection is straightforward once you understand the pieces involved.

How Monday.com Receives Data from External Sources

Monday.com accepts incoming data through its REST API. When you want to create a new item in a Monday board from a form submission, you send a request to Monday's API with the field values mapped to the columns in your board.

Monday.com uses GraphQL for its API, which means you send structured queries rather than simple POST bodies. A basic item creation request looks like this:

POST https://api.monday.com/v2
Authorization: Bearer YOUR_MONDAY_API_TOKEN
Content-Type: application/json

{
  "query": "mutation { create_item (board_id: YOUR_BOARD_ID, item_name: \"CONTACT_NAME\", column_values: \"{\\\"email\\\": {\\\"email\\\": \\\"EMAIL\\\", \\\"text\\\": \\\"EMAIL\\\"}}\") { id } }"
}

You get your API token from Monday.com under your profile avatar at the top right, then Admin, then API. Your board ID appears in the URL when you open the board.

This is the call that needs to happen automatically every time someone submits your CF7 form.

Option 1: Use Contact Form to API (Easiest, No Code)

Contact Form to API lets you connect CF7 to Monday.com directly from the WordPress dashboard. You set the Monday API endpoint, add your API token as an Authorization header, and map your CF7 fields to the Monday column values.

When someone submits your form, the plugin sends the data to Monday automatically. A new item appears in your board with the contact's name, email, phone, and any other fields you mapped.

This takes about ten minutes to set up and requires no code. You do not need to write GraphQL queries by hand or manage any webhook URLs. The plugin handles the outbound request and logs the response so you can confirm each submission arrived.

If you are running a business and you need leads going into Monday.com reliably, this is the approach that saves the most time and causes the fewest problems long term.

Option 2: Webhook Approach (More Setup, More Fragile)

The person in the forum asked whether webhooks are a good approach. Technically yes, but it involves more moving parts.

A webhook approach typically means setting up a third-party automation tool like Zapier or Make between CF7 and Monday.com. CF7 sends form data to the automation tool, which then sends it to Monday.

The problem with this approach is the cost and the dependency chain. Zapier charges per task. Make charges per operation. Every form submission uses up credits. If the automation tool has downtime or changes their pricing, your integration breaks or becomes expensive.

There are also more points of failure. The form submits to CF7, CF7 sends to the automation tool, the automation tool sends to Monday. Any of those steps can fail silently.

A direct API connection from CF7 to Monday removes the middle layer entirely.

Option 3: Custom PHP Code

If you are comfortable with PHP, you can write a function that hooks into CF7's submission event and sends data directly to Monday's GraphQL API.

add_action('wpcf7_before_send_mail', 'send_cf7_to_monday');

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

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

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

    $token    = defined('MONDAY_API_TOKEN') ? MONDAY_API_TOKEN : '';
    $board_id = defined('MONDAY_BOARD_ID')  ? MONDAY_BOARD_ID  : '';

    $column_values = json_encode([
        'email' => ['email' => $email, 'text' => $email],
    ]);

    $query = 'mutation { create_item (board_id: ' . $board_id . ', item_name: "' . esc_js($name) . '", column_values: "' . addslashes($column_values) . '") { id } }';

    wp_remote_post('https://api.monday.com/v2', [
        'headers' => [
            'Authorization' => 'Bearer ' . $token,
            'Content-Type'  => 'application/json',
        ],
        'body'    => wp_json_encode(['query' => $query]),
        'timeout' => 15,
    ]);
}

Add your token and board ID to wp-config.php:

define('MONDAY_API_TOKEN', 'your-token-here');
define('MONDAY_BOARD_ID',  '1234567890');

This works but requires you to maintain the code, update it when your form changes, and handle errors yourself.

Which Approach Is Right for You

If you want leads in Monday.com starting today without writing code, use Contact Form to API. It was built exactly for this kind of CF7-to-CRM connection and handles the API call, authentication, and field mapping from a simple admin interface.

If you already have Zapier or Make and use it for other things, the webhook route adds one more zap or scenario. Expect to pay per submission.

If you are a developer and want full control, the custom PHP approach is clean and maintainable as long as you are comfortable owning it.

Most WordPress site owners who ask "how do I connect CF7 to Monday" are looking for the no-code path. That is Contact Form to API.

CF7 Webhook Throwing a 500 Error? Checkboxes and Acceptance Fields Are Probably the Cause

Rahul Sharma — Tue, 16 Jun 2026 12:37:52 +0000

You set up a webhook in CF7 to send form data to an external service. You test it with a simple email field and it works perfectly. Then you add a checkbox, an acceptance field, or a multi-select dropdown to your form and suddenly every submission throws a 500 error.

The form stops working entirely. No data reaches your webhook. Your visitors see a broken form.

This is a real bug that was reported on the WordPress support forums and confirmed across WordPress 6.9, PHP 8.2, and CF7 6.1.4. Here is exactly what is happening and how to fix it.

What Is Actually Going Wrong

When a user submits a CF7 form, the webhook feature takes the field values and replaces the placeholders in your webhook body template with the actual submitted values.

For a simple text or email field, the value is a plain string. The replacement works fine.

But checkbox fields, acceptance fields, and multi-select dropdowns return arrays in PHP, not strings. When the webhook code tries to do a string replacement with an array value, PHP throws a fatal error:

PHP Fatal error: Uncaught TypeError: str_replace(): Argument #2 ($replace)
must be of type string when argument #1 ($search) is a string
in webhook.php:464

The CF7 Apps plugin assumed every field value would be a string. Acceptance checkboxes, regular checkboxes, and multi-select dropdowns break that assumption because they return multiple selected values as an array.

The result: a 500 server error on every submission that includes those field types.

Which Field Types Trigger This Error

Three CF7 field types cause this problem:

Acceptance fields — the GDPR consent checkbox that CF7 provides:

[acceptance accept-terms] I agree to the terms[/acceptance]

Checkbox fields — any field using [checkbox]:

[checkbox services "Web Design" "SEO" "Hosting"]

Dropdowns with the multiple attribute — allowing users to select more than one option:

[select* services multiple "Option 1" "Option 2" "Option 3"]

All three return arrays from CF7's submission handler. Any webhook plugin that does not handle arrays will throw the same fatal error.

The Quick Fix If You Must Keep Using CF7 Apps Webhook

The CF7 Apps team released a beta fix for this bug. If you are already committed to using their webhook feature, download the beta from their support thread and install it manually.

However, be aware that even after the fix, single-select dropdowns send their values as a JSON array with one item rather than a plain string. So a user selecting "Option 2" from a dropdown arrives at your webhook as ["Option 2"] instead of "Option 2". Depending on what your receiving API expects, this may cause further problems.

The Better Fix: Use a Plugin That Handles Arrays Properly From the Start

Patching around bugs in webhook plugins is a maintenance burden. Every time CF7 updates or the webhook plugin updates, you risk the same class of problem coming back.

Contact Form to API was built specifically to handle CF7 form data and send it to external APIs correctly. It handles checkbox arrays, acceptance fields, and multi-select dropdowns without throwing 500 errors because it processes CF7's submission data properly before building the outbound request.

You get a clean configuration interface where you map CF7 fields to your API's expected format, set your endpoint URL, configure authentication headers, and test the connection all from the WordPress dashboard. No fatal PHP errors. No broken forms.

Why This Keeps Happening With CF7 Webhooks

CF7's field types fall into two categories: fields that return a single string value (text, email, phone, textarea) and fields that return arrays (checkboxes, acceptance, multi-select). Most webhook plugins are built and tested only with the simple string fields. Array fields get added to forms later and the webhook silently breaks.

The pattern repeats across different plugins because the underlying issue is the same: not checking the type of a field value before doing string operations on it.

If your form collects consent, services selected, or any kind of multi-option choice, you need a webhook or API integration tool that explicitly handles arrays. Contact Form to API converts array field values (comma-separated or serialized) into a format your API can consume, so your checkbox selections arrive at your CRM cleanly rather than crashing the whole submission.

What to Check If You Are Seeing a 500 Error

If your CF7 form is throwing a 500 error on submission and you have a webhook configured, check these things in order:

First, look at your server's PHP error log. The error will include a stack trace pointing to the exact file and line. If you see str_replace() with a TypeError about array arguments, this is the same bug described here.

Second, check whether your form contains any checkbox, acceptance, or multi-select dropdown fields. Remove them temporarily and test the form. If the 500 error disappears, those fields are the trigger.

Third, decide whether to patch the existing webhook plugin or switch to a tool that handles CF7 field types correctly. If you are managing more than one form or more than one integration, switching to Contact Form to API pays off quickly because you manage everything from one reliable dashboard rather than hunting down bugs across multiple plugins.

CF7 File Uploads: Why the Attachment Never Arrives in Your Email

Rahul Sharma — Mon, 15 Jun 2026 07:00:51 +0000

Two developers posted the same problem on the WordPress forums. Both had the CF7 file field set up correctly in the form. Both had [your-file] in the Mail tab. Neither received the file as an attachment in their email.

One developer found the fix in a video. Here is what the video showed that the CF7 documentation does not mention anywhere:

There is a third place you need to add the file tag — the File Attachments field at the bottom of the Mail tab. Most people never scroll down far enough to see it.

That is the entire fix. But understanding why CF7 works this way, what each of the three placements actually does, and how to handle file uploads that need to go somewhere beyond email is worth covering properly.

The Three Places the File Tag Goes (And What Each One Does)

CF7's file upload has three completely separate functions that require separate tag placements:

Placement 1: The Form Tab

[file your-file filetypes:pdf|doc|docx limit:2mb]

This renders the file input element in the HTML form. Without this, users have no way to select a file. This is the only placement that most tutorials cover.

Placement 2: The Mail Tab Body

School/Organization Logo: [your-file]

This inserts the filename (not the file itself) into the email body as text. It tells you what file was uploaded but does not attach it. This is where the confusion starts. Both developers in the thread had this placement and assumed it would attach the file. It does not. It just prints the filename as a string.

Placement 3: The Mail Tab File Attachments Field

[your-file]

This is the field that actually attaches the file to the outgoing email. It is at the bottom of the Mail tab, below the Message Body field. It is easy to miss because it is small, unlabelled in some CF7 versions, and completely absent from the official documentation.

Without this third placement, the file is uploaded to your server (wp-content/uploads/wpcf7_uploads/) but never attached to the email. The email arrives with the filename mentioned in the body but no attachment.

Step by Step: Correct CF7 File Upload Configuration

Step 1: Form Tab

Use the File button in the CF7 form editor toolbar to insert the tag (do not type it manually — the UI generates a clean tag with the correct format):

[file file-upload filetypes:pdf|doc|docx|jpg|png limit:5mb]

Common mistakes in the form tag:

filetypes:image/* with the wildcard — some servers reject this. Use explicit types: image/jpeg|image/png|image/gif
Setting limit too high — hosting providers often have a lower upload_max_filesize in php.ini than what you set in CF7. CF7's limit cannot exceed the server's PHP limit

Step 2: Mail Tab Body (Optional)

Add this where you want the filename to appear in the email body:

Uploaded file: [file-upload]

This is optional. If you only want the attachment without mentioning it in the body, skip this placement.

Step 3: Mail Tab File Attachments Field (Required for Attachment)

Scroll to the bottom of the Mail tab. Find the field labelled File Attachments (it may be collapsed or hidden below the message body area). Add:

[file-upload]

This is the step that actually causes the file to be sent as an email attachment. Without it, the file exists on your server but never reaches the recipient's inbox.

The Filetypes Wildcard Problem

The original poster used filetypes:audio/*|video/*|image/* with wildcards. This is a CF7-supported syntax but can cause issues on some server configurations where the MIME type detection does not resolve wildcards correctly.

The safer approach is explicit MIME types:

[file your-file filetypes:image/jpeg|image/png|image/gif|image/webp|audio/mpeg|video/mp4 limit:1mb]

Or for common document uploads:

[file your-file filetypes:pdf|doc|docx|xls|xlsx|txt limit:5mb]

CF7 accepts both MIME type strings and file extensions. File extensions are simpler to read and work reliably across server configurations.

Where Uploaded Files Actually Go

Files uploaded through CF7 go to wp-content/uploads/wpcf7_uploads/ temporarily. CF7 deletes them after the email is sent. They are not permanently stored on your server.

This is what the original poster saw in Flamingo: a number (the temporary file ID) rather than a clickable link. Flamingo records that a file was submitted but does not store the file itself. Once CF7 processes the form and sends the email, the file is gone from the server.

If you need permanent file storage (files accessible after the email is sent), you have two options:

Option 1: Use a plugin like "CF7 to Post" or "CF7 Storage" to save uploads permanently alongside the form submission record.

Option 2: Forward the file to external storage via API. Contact Form to API can send form submission data including file references to an external endpoint where the file can be stored in cloud storage (S3, Google Drive, Dropbox, etc.) as part of a webhook workflow.

Making Fields Optional

The second question in the thread: how to make certain fields optional.

In CF7, field tags with an asterisk are required:

[text* your-name]    <- required
[text your-company]  <- optional

Remove the asterisk to make a field optional. For file uploads:

[file your-file filetypes:pdf limit:5mb]         <- optional upload
[file* your-file-required filetypes:pdf limit:5mb] <- required upload

Optional file fields do not block form submission if left empty. Required fields with * trigger CF7's validation and prevent submission if no file is selected.

Quick Reference

Placement	Location	What it does
`[file your-file ...]`	Form tab	Renders the file input in the HTML form
`[your-file]` in body	Mail tab body	Inserts the filename as text in the email body
`[your-file]` in File Attachments	Mail tab bottom	Actually attaches the file to the outgoing email

All three are needed if you want the file to appear as an email attachment. The third one is the one nobody mentions and the one that solves the problem.

How to Use a CF7 Field to Query an External API and Populate Other Fields

Rahul Sharma — Fri, 12 Jun 2026 11:28:35 +0000

A developer asked on the WordPress forums: can a CF7 field value be used to query an external API and populate other fields on the same form?

The plugin author replied: not out of the box, you need custom AJAX code and JavaScript. Thread closed.

That answer points in the right direction but gives nothing to work with. This post builds the complete implementation: a WordPress AJAX proxy endpoint on the server side (to keep your API keys out of the browser), JavaScript that fires on field input, and DOM manipulation that populates CF7 fields from the API response.

Why You Need a Server-Side Proxy

The instinct is to call the external API directly from JavaScript in the browser. Do not do this if the API requires an API key or any form of authentication.

Calling an authenticated API from client-side JavaScript exposes your credentials in the browser's network tab. Anyone can open DevTools, copy your API key, and use it against your quota or billing account.

The correct pattern is a two-hop architecture:

User types in CF7 field
        |
        | fetch() to your WordPress AJAX endpoint
        v
WordPress handles the request server-side
        |
        | wp_remote_get() with your API key (never visible to browser)
        v
External API returns data
        |
        | WordPress passes sanitized response back to browser
        v
JavaScript populates the other CF7 fields

Your API key lives only in wp-config.php. The browser never sees it.

Step 1: Register the WordPress AJAX Endpoint

// Register for both logged-in and non-logged-in users
// (CF7 forms are typically on public pages)
add_action('wp_ajax_cf7_api_lookup',        'cf7_api_lookup_handler');
add_action('wp_ajax_nopriv_cf7_api_lookup', 'cf7_api_lookup_handler');

function cf7_api_lookup_handler(): void {
    // Verify the nonce to prevent CSRF abuse of your proxy
    check_ajax_referer('cf7_api_lookup_nonce', 'nonce');

    $query = sanitize_text_field($_POST['query'] ?? '');

    if (empty($query)) {
        wp_send_json_error(['message' => 'Query is required'], 400);
    }

    // Validate format if needed (e.g. postcode pattern, company number format)
    // if (!preg_match('/^\d{5}$/', $query)) {
    //     wp_send_json_error(['message' => 'Invalid format'], 422);
    // }

    $api_key = defined('EXTERNAL_API_KEY') ? EXTERNAL_API_KEY : '';
    $api_url = add_query_arg(
        ['q' => urlencode($query), 'key' => $api_key],
        'https://api.example.com/v1/lookup'
    );

    $response = wp_remote_get($api_url, [
        'timeout' => 8,
        'headers' => ['Accept' => 'application/json'],
    ]);

    if (is_wp_error($response)) {
        wp_send_json_error(['message' => 'API request failed'], 502);
    }

    $status = wp_remote_retrieve_response_code($response);
    $body   = json_decode(wp_remote_retrieve_body($response), true);

    if ($status !== 200 || empty($body)) {
        wp_send_json_error(['message' => 'No results found'], 404);
    }

    // Return only the fields you need — do not expose raw API response to browser
    wp_send_json_success([
        'company_name'    => sanitize_text_field($body['company']['name']     ?? ''),
        'street_address'  => sanitize_text_field($body['address']['street']   ?? ''),
        'city'            => sanitize_text_field($body['address']['city']     ?? ''),
        'postcode'        => sanitize_text_field($body['address']['postcode'] ?? ''),
    ]);
}

Store your API key in wp-config.php:

define('EXTERNAL_API_KEY', 'your-api-key-here');

Step 2: Pass the Nonce to JavaScript

WordPress AJAX requires a nonce for wp_ajax_nopriv_ endpoints. Pass it to your script using wp_localize_script:

add_action('wp_enqueue_scripts', 'cf7_api_lookup_enqueue');

function cf7_api_lookup_enqueue(): void {
    // Only enqueue on pages that have the CF7 form
    // Adjust the condition to match where your form appears
    wp_enqueue_script(
        'cf7-api-lookup',
        get_template_directory_uri() . '/js/cf7-api-lookup.js',
        ['jquery'],
        '1.0.0',
        true
    );

    wp_localize_script('cf7-api-lookup', 'CF7ApiLookup', [
        'ajaxUrl' => admin_url('admin-ajax.php'),
        'nonce'   => wp_create_nonce('cf7_api_lookup_nonce'),
    ]);
}

Step 3: The JavaScript

This is where the CF7 field triggers the lookup and the other fields get populated.

// js/cf7-api-lookup.js

(function() {
    'use strict';

    // Debounce: wait until the user stops typing before firing the API call
    function debounce(fn, delay) {
        let timer;
        return function(...args) {
            clearTimeout(timer);
            timer = setTimeout(() => fn.apply(this, args), delay);
        };
    }

    function showStatus(inputEl, message, type) {
        // type: 'loading' | 'success' | 'error' | ''
        let statusEl = inputEl.parentElement.querySelector('.cf7-lookup-status');
        if (!statusEl) {
            statusEl = document.createElement('span');
            statusEl.className = 'cf7-lookup-status';
            statusEl.style.cssText = 'display:block;font-size:0.85em;margin-top:4px;';
            inputEl.parentElement.appendChild(statusEl);
        }
        const colors = { loading: '#888', success: '#2a7', error: '#c33', '': '#888' };
        statusEl.style.color = colors[type] || '#888';
        statusEl.textContent  = message;
    }

    function clearFields(fieldNames) {
        fieldNames.forEach(function(name) {
            const el = document.querySelector('[name="' + name + '"]');
            if (el) el.value = '';
        });
    }

    function populateFields(data) {
        // Map API response keys to CF7 field names
        // Adjust these to match your actual CF7 field names
        const fieldMap = {
            company_name:   'company-name',
            street_address: 'street-address',
            city:           'city',
            postcode:       'postcode',
        };

        Object.entries(fieldMap).forEach(function([dataKey, fieldName]) {
            const el = document.querySelector('[name="' + fieldName + '"]');
            if (el && data[dataKey]) {
                el.value = data[dataKey];
                // Trigger change event so CF7 validation re-evaluates
                el.dispatchEvent(new Event('change', { bubbles: true }));
            }
        });
    }

    function doLookup(value, triggerInput) {
        if (!value || value.length < 3) return;

        showStatus(triggerInput, 'Looking up...', 'loading');
        clearFields(['company-name', 'street-address', 'city', 'postcode']);

        const formData = new FormData();
        formData.append('action', 'cf7_api_lookup');
        formData.append('nonce',  CF7ApiLookup.nonce);
        formData.append('query',  value);

        fetch(CF7ApiLookup.ajaxUrl, {
            method: 'POST',
            body:   formData,
        })
        .then(function(res) { return res.json(); })
        .then(function(response) {
            if (response.success) {
                populateFields(response.data);
                showStatus(triggerInput, 'Details found', 'success');
            } else {
                showStatus(triggerInput, response.data.message || 'No results found', 'error');
            }
        })
        .catch(function() {
            showStatus(triggerInput, 'Lookup failed. Please fill in manually.', 'error');
        });
    }

    document.addEventListener('DOMContentLoaded', function() {
        // Replace 'company-number' with your actual CF7 trigger field name
        const triggerInput = document.querySelector('[name="company-number"]');
        if (!triggerInput) return;

        const debouncedLookup = debounce(function(e) {
            doLookup(e.target.value.trim(), triggerInput);
        }, 600); // fires 600ms after the user stops typing

        triggerInput.addEventListener('input', debouncedLookup);
    });

})();

What the 600ms Debounce Does

Without debouncing, every keystroke fires an AJAX request. A user typing "12345" produces five requests, four of which are abandoned as the user keeps typing. Debouncing waits until the user stops for 600ms before firing. This reduces API calls from one-per-keystroke to one-per-completed-entry.

For postcode or company number lookups where users typically paste the value rather than type it, you can also listen on blur (when the field loses focus) instead of input:

triggerInput.addEventListener('blur', function(e) {
    doLookup(e.target.value.trim(), triggerInput);
});

blur fires exactly once when the user leaves the field, regardless of how many characters they typed.

Making Populated Fields Required in CF7

If you want CF7's built-in validation to treat auto-populated fields as required, they need to be marked as required in your CF7 form builder using [text* field-name]. The * makes the field required. Since your JavaScript populates them before submission, CF7 will validate them as filled.

If a user skips the trigger field and the populated fields remain empty, CF7 blocks the form submission with a validation error on the required fields. This is the correct behaviour.

Using Contact Form to API for the Submission Side

This pattern handles the lookup before submission. For sending the submitted data (including the populated fields) to an external API after the user clicks submit, Contact Form to API handles the outbound POST to your CRM or backend without custom PHP on the submission side. The two approaches work together: JavaScript for the lookup, Contact Form to API for the outbound submission.

Quick Checklist

AJAX endpoint registered for both wp_ajax_ and wp_ajax_nopriv_
Nonce verified in the handler with check_ajax_referer()
API key in wp-config.php constants, never in JavaScript
Response sanitized before sending back to browser
Debounce set on the trigger field (600ms for typing, or use blur)
dispatchEvent(new Event('change')) after populating each field so CF7 validation re-evaluates

"Invalid OAuth2 Access Token" in CF7 Google Sheets Connector: What the Stack Trace Actually Tells You

Rahul Sharma — Thu, 11 Jun 2026 11:23:15 +0000

A developer posted this error on the WordPress forums after connecting their CF7 form to Google Sheets:

[ERROR_MSG] => Auth, Invalid OAuth2 access token
[TRACE_STK] => #0 class-gs-service.php(182): CF7GSC_googlesheet->auth()

The plugin author replied: probably a Google library conflict with another plugin. Deactivate everything else and test.

That is one of three possible causes. The stack trace tells you much more if you know how to read it. This post breaks down what is actually happening, why this error appears even when your connection was working fine, and how to fix each cause.

Reading the Stack Trace

The stack trace is not noise. It is a precise execution path. Here is what it tells you:

#0  class-gs-service.php(182): CF7GSC_googlesheet->auth()
#1  class-wp-hook.php(308):    Gs_Connector_Service->cf7_save_to_google_sheets()
#4  submission.php(119):       do_action('wpcf7_mail_sent', ...)
#10 rest-api.php(357):         WPCF7_ContactForm->submit()

Reading bottom-up (which is how stack traces work):

A user submits a CF7 form via the REST API (rest-api.php)
CF7 processes the submission (submission.php)
CF7 fires the wpcf7_mail_sent action after the email is sent (submission.php:119)
GSheetConnector catches that hook and calls cf7_save_to_google_sheets()
That function calls auth() to validate the Google OAuth token
auth() fails with Invalid OAuth2 access token

The form submitted successfully. The email was sent. The Google Sheets write is what failed. This is important: the form is not broken, only the Sheets logging is broken.

The failure happens at class-gs-service.php(182) inside the auth() method. That method calls Google's OAuth token validation endpoint. The token it holds is being rejected by Google.

Three Causes of "Invalid OAuth2 Access Token"

Cause 1: Google OAuth Token Expired (Most Common)

Google OAuth access tokens issued through the standard authorization flow expire. When GSheetConnector connects to Google, it stores:

An access token (short-lived, expires in 1 hour)
A refresh token (long-lived, used to get new access tokens)

The plugin should automatically use the refresh token to get a new access token before each Sheets write. If the refresh token itself has expired or been revoked, no new access token can be generated and every write fails with this error.

When do refresh tokens expire or get revoked?

Google revokes refresh tokens after 7 days if the OAuth app is in "Testing" status in Google Cloud Console (not published/verified)
Refresh tokens are revoked when the user changes their Google account password
Refresh tokens are revoked when the user revokes app access in their Google Account > Security > Third-party apps
Google revokes tokens for apps that have been inactive for 6 months
Each user account is limited to 50 active refresh tokens per app. The 51st token revokes the oldest one.

The 7-day expiry is the most common cause for developers using GSheetConnector. If you connected successfully, it worked for a week, then broke, this is almost certainly what happened. Your app is in Testing status in Google Cloud Console.

Fix: Publish your OAuth app in Google Cloud Console (change from Testing to Production), then reconnect the plugin. Or reconnect every 7 days if you intentionally keep it in Testing.

Cause 2: Google Client Library Version Conflict

This is what the plugin author pointed to. The GSheetConnector plugin bundles a version of Google's PHP client library (google/apiclient). Other plugins that integrate with Google services (Google Analytics, Google Ads, Google Tag Manager plugins, WooCommerce Google integrations) may bundle a different version of the same library.

When two plugins load different versions of Google_Client, Google_Service_Sheets, or related classes, PHP class conflicts occur. Depending on which plugin loads first, the wrong version of the auth class runs. The token validation logic in the wrong version may reject tokens it should accept, or fail silently.

How to confirm:

Deactivate all other Google-related plugins one by one. If the error disappears after deactivating a specific plugin, that is the conflicting one.

You can also check for class conflicts:

// Add temporarily to functions.php
add_action('plugins_loaded', function() {
    if (class_exists('Google_Client')) {
        $reflection = new ReflectionClass('Google_Client');
        error_log('Google_Client loaded from: ' . $reflection->getFileName());
    }
});

If the path shown does not point to GSheetConnector's directory, another plugin loaded its version first.

Fix: Use a plugin that handles Google library loading with proper namespacing or version isolation. Or use Contact Form to API to send CF7 data to Google Sheets via the Sheets API directly with a Bearer token, bypassing the shared library problem entirely.

Cause 3: Wrong Google Account or Revoked Access

If the Google account used to authorize GSheetConnector has had its access revoked (either manually by the user or automatically by Google), the stored tokens are invalid.

Common scenarios:

The Google account used for authorization belongs to a team member who left the organization and had their account suspended
The Google Workspace admin revoked third-party app access across the organization
The specific Google Sheet was moved to a different Drive account that the authorized user cannot access

Fix: Reconnect the plugin using the correct Google account that has access to the target spreadsheet.

Verifying the Token State Without the Plugin

You can test whether a stored token is valid directly:

# Test if an access token is valid
curl "https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=YOUR_ACCESS_TOKEN"

A valid token returns:

{
  "issued_to": "your-client-id.apps.googleusercontent.com",
  "audience": "your-client-id.apps.googleusercontent.com",
  "scope": "https://www.googleapis.com/auth/spreadsheets",
  "expires_in": 3412,
  "access_type": "online"
}

An invalid or expired token returns:

{
  "error": "invalid_token",
  "error_description": "Token has been expired or revoked."
}

If you get invalid_token here, the stored access token is genuinely expired. The question is whether the refresh token is also expired. If it is, reconnecting the plugin from scratch is the only fix.

Checking Google Cloud Console OAuth App Status

This is the step most developers miss. Go to:

Google Cloud Console
Select your project
Go to APIs and Services > OAuth consent screen
Check the Publishing status

If it says Testing, your refresh tokens expire after 7 days and only test users you have explicitly added can authorize the app. Change to Production (you do not need Google verification for internal tools used by your own account) to get non-expiring refresh tokens.

The Direct API Alternative

GSheetConnector's OAuth dependency is the source of all three failure modes above. The plugin needs a valid access token every time a form submits. If the token lifecycle breaks for any reason, all Sheets writes fail silently (or with this error logged to PHP error logs that most site owners never check).

An alternative is to connect CF7 directly to the Google Sheets API using a Service Account instead of OAuth user authorization. Service accounts use a JSON key file for authentication and do not have token expiry issues in the same way.

The Google Sheets API endpoint for appending a row:

POST https://sheets.googleapis.com/v4/spreadsheets/{spreadsheetId}/values/{range}:append
Authorization: Bearer SERVICE_ACCOUNT_ACCESS_TOKEN
Content-Type: application/json

{
  "values": [["John Smith", "john@example.com", "2024-01-15"]]
}

Contact Form to API can send CF7 form data to this endpoint directly, with the service account token handled separately from the plugin's OAuth flow. This removes the shared Google library dependency and the 7-day token expiry problem.

Diagnosis Checklist

Work through these in order:

Check Google Cloud Console OAuth consent screen — is the app in Testing status?
Has it been more than 7 days since you last connected the plugin?
Did the Google account owner change their password recently?
Are there other Google-related plugins active? Deactivate them one by one.
Does the authorized Google account still have access to the target spreadsheet?
Test the access token directly with the tokeninfo endpoint above

Why CF7 Plugin Settings Stop Saving After a CF7 Update (And How to Fix It)

Rahul Sharma — Wed, 10 Jun 2026 08:12:00 +0000

A developer posted on the WordPress support forums:

"The API settings via the plugin cannot be saved. Whenever I click Save after completing the form, the text fields are empty again."

Another user confirmed the same issue and traced it to a CF7 version update:

"I'm noticing the same issue for sites that updated Contact Form 7 to version 5.5.3. Rolling back to 5.5.2 fixed it for me."

Thread closed. Not resolved.

Rolling back is not a fix. It is a temporary workaround that leaves your site running an outdated plugin version indefinitely. The actual problem is a CF7 architectural change in 5.5.x that broke how certain third-party plugins registered and saved their settings. Understanding what changed, why it breaks settings saving, and how to build integrations that survive CF7 version bumps is what this post covers.

What Changed in CF7 5.5.x

CF7 version 5.5 introduced significant internal changes to how the plugin manages its admin pages and settings. Specifically:

Menu registration changed. CF7 moved from using add_menu_page() with its own top-level admin menu to a restructured settings architecture. Third-party plugins that hooked into CF7's admin menu using the old approach found their settings pages either disappearing or failing to process $_POST correctly.

Nonce handling tightened. CF7 5.5.x tightened nonce verification on its settings save handlers. Third-party plugins that piggy-backed on CF7's options.php flow without registering their own nonces correctly started failing silently on save.

Settings API registration assumptions broke. Some CF7 add-on plugins assumed CF7's internal action names and page slugs were stable. When CF7 renamed internal hooks and page identifiers in 5.5, any plugin that referenced those by name stopped working.

The result: you click Save, the page reloads, and the fields are empty. No error message. No debug log entry. The settings were never written to the database.

Why Settings Appear to Save But Do Not

When a WordPress settings form submits and the data does not persist, one of four things is happening:

1. Nonce verification failed

WordPress settings forms include a nonce field for CSRF protection. If the nonce is invalid, expired, or missing, WordPress rejects the $_POST data silently and redirects back to the settings page. The fields appear empty because the data was never saved.

Check by temporarily adding to wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

Then save the settings and check wp-content/debug.log for nonce-related warnings.

2. The settings were not registered with register_setting()

WordPress's Settings API requires that any option saved via options.php is registered with register_setting($option_group, $option_name). If a plugin saves settings through options.php but did not call register_setting(), WordPress 4.9+ silently discards the unregistered options.

3. The form action attribute points to the wrong handler

If a plugin's settings form submits to options.php but the plugin's $option_group does not match what settings_fields() outputs, the nonce check fails and nothing saves.

4. A PHP error occurs during the save handler

If the plugin's register_setting() sanitize callback throws a PHP error or warning, WordPress may abort the save process mid-execution. With error display off (production sites), this looks identical to a nonce failure.

The Correct Pattern for CF7 Add-On Settings That Survive Version Changes

The mistake most CF7 add-on plugins make is coupling their settings registration to CF7's internal page hooks. When CF7 changes those hooks, the add-on breaks.

The correct pattern is to register settings completely independently of CF7's internals:

// 1. Register your own settings page independently
add_action('admin_menu', 'myplugin_register_settings_page');

function myplugin_register_settings_page() {
    add_options_page(
        'My CF7 Integration Settings',
        'CF7 Integration',
        'manage_options',
        'myplugin-cf7-settings',
        'myplugin_render_settings_page'
    );
}

// 2. Register your options with the Settings API
add_action('admin_init', 'myplugin_register_settings');

function myplugin_register_settings() {
    register_setting(
        'myplugin_cf7_settings_group',   // option group
        'myplugin_api_endpoint',          // option name
        [
            'type'              => 'string',
            'sanitize_callback' => 'esc_url_raw',
            'default'           => '',
        ]
    );

    register_setting(
        'myplugin_cf7_settings_group',
        'myplugin_api_username',
        [
            'type'              => 'string',
            'sanitize_callback' => 'sanitize_text_field',
            'default'           => '',
        ]
    );

    register_setting(
        'myplugin_cf7_settings_group',
        'myplugin_api_password',
        [
            'type'              => 'string',
            'sanitize_callback' => 'sanitize_text_field',
            'default'           => '',
        ]
    );
}

// 3. Render the settings form correctly
function myplugin_render_settings_page() {
    if (!current_user_can('manage_options')) {
        wp_die('Insufficient permissions');
    }
    ?>
    <div class="wrap">
        <h1>CF7 Integration Settings</h1>
        <form method="post" action="options.php">
            <?php
            // This outputs the nonce, action, and option_page fields correctly
            settings_fields('myplugin_cf7_settings_group');
            ?>
            <table class="form-table">
                <tr>
                    <th>API Endpoint</th>
                    <td>
                        <input type="url"
                               name="myplugin_api_endpoint"
                               value="<?php echo esc_attr(get_option('myplugin_api_endpoint')); ?>"
                               class="regular-text" />
                    </td>
                </tr>
                <tr>
                    <th>Username</th>
                    <td>
                        <input type="text"
                               name="myplugin_api_username"
                               value="<?php echo esc_attr(get_option('myplugin_api_username')); ?>"
                               class="regular-text" />
                    </td>
                </tr>
                <tr>
                    <th>Password / API Key</th>
                    <td>
                        <input type="password"
                               name="myplugin_api_password"
                               value="<?php echo esc_attr(get_option('myplugin_api_password')); ?>"
                               class="regular-text" />
                    </td>
                </tr>
            </table>
            <?php submit_button(); ?>
        </form>
    </div>
    <?php
}

This approach has zero dependency on CF7's internal page hooks, menu structure, or version-specific action names. If CF7 completely rewrites its admin in a future version, these settings still save correctly.

Storing API Credentials: `get_option` vs `wp-config.php`

Storing API usernames and passwords in the WordPress database via get_option is convenient but not ideal for credentials. The database is accessible to any code running on your WordPress installation, including other plugins.

For better security, store credentials in wp-config.php as constants:

// wp-config.php
define('CF7_API_ENDPOINT', 'https://api.example.com/v1/');
define('CF7_API_USERNAME', 'your-username');
define('CF7_API_PASSWORD', 'your-api-key');

Then in your plugin:

$endpoint = defined('CF7_API_ENDPOINT') ? CF7_API_ENDPOINT : get_option('myplugin_api_endpoint');
$username = defined('CF7_API_USERNAME') ? CF7_API_USERNAME : get_option('myplugin_api_username');
$password = defined('CF7_API_PASSWORD') ? CF7_API_PASSWORD : get_option('myplugin_api_password');

This pattern lets you use wp-config.php constants on servers where you control the environment (staging, production) and fall back to the database UI for development environments where constants are not defined.

Basic Auth: What It Is and When It Is Acceptable

The plugin in this thread is named "CF7 to API + Basic Auth," so it is worth being precise about what Basic Auth is and its limitations.

Basic Auth sends credentials as a Base64-encoded string in the Authorization header:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

That encoded string is username:password in Base64. It is trivially decodable. Base64 is encoding, not encryption.

Basic Auth is acceptable when:

The connection is over HTTPS (TLS encrypts the header in transit)
The API has no more secure auth option available
The credentials have minimal scope (read-only or limited write access)

Basic Auth is not acceptable when:

The connection is over plain HTTP (credentials are visible to any network observer)
The API supports OAuth 2.0 or API key-based auth (use those instead)
The credentials are high-privilege account credentials rather than scoped API keys

For CF7 integrations sending form data to an external API, Bearer token auth is preferable to Basic Auth when the API supports it. Bearer tokens can be scoped, rotated, and revoked without changing account passwords.

Contact Form to API supports both Basic Auth and Bearer token authentication, and stores credentials in a way that survives CF7 version updates without breaking the settings page.

Diagnosing Settings That Do Not Save

Run this checklist before doing anything else:

// Add temporarily to functions.php to debug settings saves
add_action('updated_option', function($option_name, $old_value, $new_value) {
    if (strpos($option_name, 'myplugin') !== false) {
        error_log('Option updated: ' . $option_name . ' = ' . print_r($new_value, true));
    }
}, 10, 3);

add_action('update_option', function($option_name, $old_value, $new_value) {
    if (strpos($option_name, 'myplugin') !== false) {
        error_log('Attempting to update: ' . $option_name);
    }
}, 10, 3);

If update_option fires but updated_option does not, the value being saved matches the existing value (no change, so WordPress skips the write). If neither fires, the $_POST data never reached the options handler, which points to a nonce failure or unregistered option.

The Real Fix vs Rolling Back

Rolling back CF7 to 5.5.2 stops the breakage temporarily. It does not fix the underlying issue and leaves you running an outdated plugin with unpatched security issues.

The real fix is either:

Update the broken add-on plugin to use CF7-version-agnostic settings registration (as shown above)
Replace the broken plugin with one that does not rely on CF7's internal admin architecture

Contact Form to API registers its settings independently of CF7's internals and has maintained compatibility across CF7 major versions without requiring rollbacks.

Why CF7 Plugin Settings Stop Saving After a CF7 Update (And How to Fix It)

Rahul Sharma — Mon, 08 Jun 2026 05:34:21 +0000

A developer posted on the WordPress support forums:

"The API settings via the plugin cannot be saved. Whenever I click Save after completing the form, the text fields are empty again."

Another user confirmed the same issue and traced it to a CF7 version update:

"I'm noticing the same issue for sites that updated Contact Form 7 to version 5.5.3. Rolling back to 5.5.2 fixed it for me."

Thread closed. Not resolved.

What Changed in CF7 5.5.x

CF7 version 5.5 introduced significant internal changes to how the plugin manages its admin pages and settings. Specifically:

The result: you click Save, the page reloads, and the fields are empty. No error message. No debug log entry. The settings were never written to the database.

Why Settings Appear to Save But Do Not

When a WordPress settings form submits and the data does not persist, one of four things is happening:

1. Nonce verification failed

Check by temporarily adding to wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

Then save the settings and check wp-content/debug.log for nonce-related warnings.

2. The settings were not registered with register_setting()

3. The form action attribute points to the wrong handler

If a plugin's settings form submits to options.php but the plugin's $option_group does not match what settings_fields() outputs, the nonce check fails and nothing saves.

4. A PHP error occurs during the save handler

The Correct Pattern for CF7 Add-On Settings That Survive Version Changes

The mistake most CF7 add-on plugins make is coupling their settings registration to CF7's internal page hooks. When CF7 changes those hooks, the add-on breaks.

The correct pattern is to register settings completely independently of CF7's internals:

// 1. Register your own settings page independently
add_action('admin_menu', 'myplugin_register_settings_page');

function myplugin_register_settings_page() {
    add_options_page(
        'My CF7 Integration Settings',
        'CF7 Integration',
        'manage_options',
        'myplugin-cf7-settings',
        'myplugin_render_settings_page'
    );
}

// 2. Register your options with the Settings API
add_action('admin_init', 'myplugin_register_settings');

function myplugin_register_settings() {
    register_setting(
        'myplugin_cf7_settings_group',   // option group
        'myplugin_api_endpoint',          // option name
        [
            'type'              => 'string',
            'sanitize_callback' => 'esc_url_raw',
            'default'           => '',
        ]
    );

    register_setting(
        'myplugin_cf7_settings_group',
        'myplugin_api_username',
        [
            'type'              => 'string',
            'sanitize_callback' => 'sanitize_text_field',
            'default'           => '',
        ]
    );

    register_setting(
        'myplugin_cf7_settings_group',
        'myplugin_api_password',
        [
            'type'              => 'string',
            'sanitize_callback' => 'sanitize_text_field',
            'default'           => '',
        ]
    );
}

// 3. Render the settings form correctly
function myplugin_render_settings_page() {
    if (!current_user_can('manage_options')) {
        wp_die('Insufficient permissions');
    }
    ?>
    <div class="wrap">
        <h1>CF7 Integration Settings</h1>
        <form method="post" action="options.php">
            <?php
            // This outputs the nonce, action, and option_page fields correctly
            settings_fields('myplugin_cf7_settings_group');
            ?>
            <table class="form-table">
                <tr>
                    <th>API Endpoint</th>
                    <td>
                        <input type="url"
                               name="myplugin_api_endpoint"
                               value="<?php echo esc_attr(get_option('myplugin_api_endpoint')); ?>"
                               class="regular-text" />
                    </td>
                </tr>
                <tr>
                    <th>Username</th>
                    <td>
                        <input type="text"
                               name="myplugin_api_username"
                               value="<?php echo esc_attr(get_option('myplugin_api_username')); ?>"
                               class="regular-text" />
                    </td>
                </tr>
                <tr>
                    <th>Password / API Key</th>
                    <td>
                        <input type="password"
                               name="myplugin_api_password"
                               value="<?php echo esc_attr(get_option('myplugin_api_password')); ?>"
                               class="regular-text" />
                    </td>
                </tr>
            </table>
            <?php submit_button(); ?>
        </form>
    </div>
    <?php
}

Storing API Credentials: `get_option` vs `wp-config.php`

For better security, store credentials in wp-config.php as constants:

// wp-config.php
define('CF7_API_ENDPOINT', 'https://api.example.com/v1/');
define('CF7_API_USERNAME', 'your-username');
define('CF7_API_PASSWORD', 'your-api-key');

Then in your plugin:

$endpoint = defined('CF7_API_ENDPOINT') ? CF7_API_ENDPOINT : get_option('myplugin_api_endpoint');
$username = defined('CF7_API_USERNAME') ? CF7_API_USERNAME : get_option('myplugin_api_username');
$password = defined('CF7_API_PASSWORD') ? CF7_API_PASSWORD : get_option('myplugin_api_password');

Basic Auth: What It Is and When It Is Acceptable

The plugin in this thread is named "CF7 to API + Basic Auth," so it is worth being precise about what Basic Auth is and its limitations.

Basic Auth sends credentials as a Base64-encoded string in the Authorization header:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

That encoded string is username:password in Base64. It is trivially decodable. Base64 is encoding, not encryption.

Basic Auth is acceptable when:

The connection is over HTTPS (TLS encrypts the header in transit)
The API has no more secure auth option available
The credentials have minimal scope (read-only or limited write access)

Basic Auth is not acceptable when:

The connection is over plain HTTP (credentials are visible to any network observer)
The API supports OAuth 2.0 or API key-based auth (use those instead)
The credentials are high-privilege account credentials rather than scoped API keys

Contact Form to API supports both Basic Auth and Bearer token authentication, and stores credentials in a way that survives CF7 version updates without breaking the settings page.

Diagnosing Settings That Do Not Save

Run this checklist before doing anything else:

// Add temporarily to functions.php to debug settings saves
add_action('updated_option', function($option_name, $old_value, $new_value) {
    if (strpos($option_name, 'myplugin') !== false) {
        error_log('Option updated: ' . $option_name . ' = ' . print_r($new_value, true));
    }
}, 10, 3);

add_action('update_option', function($option_name, $old_value, $new_value) {
    if (strpos($option_name, 'myplugin') !== false) {
        error_log('Attempting to update: ' . $option_name);
    }
}, 10, 3);

The Real Fix vs Rolling Back

Rolling back CF7 to 5.5.2 stops the breakage temporarily. It does not fix the underlying issue and leaves you running an outdated plugin with unpatched security issues.

The real fix is either:

Update the broken add-on plugin to use CF7-version-agnostic settings registration (as shown above)
Replace the broken plugin with one that does not rely on CF7's internal admin architecture

Contact Form to API registers its settings independently of CF7's internals and has maintained compatibility across CF7 major versions without requiring rollbacks.

How to Trigger a Mailchimp Drip Sequence from a CF7 Form (Without a Checkbox)

Rahul Sharma — Fri, 05 Jun 2026 13:06:24 +0000

A developer posted this on the WordPress support forums:

"We'd like to send the auto-reply email after a visitor submits a CF7 form directly from Mailchimp. We have a drip campaign set up and a dedicated Mailchimp list. Is it possible to sign up everyone that submits a contact form to this list without displaying a checkbox?"

The reply was a link to a code snippet for setting a Mailchimp tag on CF7 submission. One sentence. Thread closed.

That answer is technically correct but skips everything that matters: how Mailchimp's automation system actually works, what the consent implications of silent opt-in are, and how to build the full CF7 to Mailchimp automation flow properly.

This post covers all of it.

What the Developer Is Actually Trying to Build

The goal is:

Visitor submits CF7 contact form
Visitor is added to a Mailchimp audience silently (no checkbox)
A tag is applied to that contact
A Mailchimp automation triggers based on that tag
The automation sends a sequence of emails (drip campaign)

This is a legitimate use case. It is used for post-inquiry follow-up sequences where the "subscription" is incidental to the contact request, not a marketing list signup.

Before building it, the consent question matters.

The Consent Question: Can You Silent-Subscribe Someone?

Mailchimp's terms of service require that contacts added to an audience have given consent to receive marketing emails. Adding someone to a Mailchimp audience without their knowledge and then sending them a marketing drip sequence is a violation of Mailchimp's terms and, depending on jurisdiction, of GDPR, CAN-SPAM, or CASL.

However, the developer's use case is transactional auto-replies, not marketing. This is a meaningful distinction:

Transactional emails are messages sent in direct response to an action the user took (submitting a form, making a purchase, requesting information). These do not require marketing consent under most regulations.

Marketing emails are messages sent to promote products, services, or content. These require explicit consent.

If your Mailchimp drip sequence is genuinely transactional (confirmation of their inquiry, information they requested, follow-up on their specific request), the consent requirement is lower. If it promotes your services beyond what was requested, it is marketing and requires consent.

Mailchimp itself does not distinguish transactional from marketing in its standard Audiences. For genuine transactional email, Mailchimp Transactional (formerly Mandrill) is the correct product. For a marketing automation triggered by a form submission with implied consent, a clear notice in your form's privacy policy link is the minimum acceptable approach.

For this post, we will assume the use case is legitimate auto-replies where the contact has reasonable expectation of receiving follow-up communication.

How Mailchimp Automations and Tags Work

Understanding the Mailchimp data model is required before writing any code.

Audience (formerly List): The top-level container for contacts in Mailchimp. Every contact belongs to one or more audiences. You pay per contact per audience.

Tag: A label applied to a contact within an audience. Tags do not add costs. A contact can have multiple tags.

Automation (Customer Journey): A sequence of emails and actions triggered by a specific event. The event that triggers the developer's drip sequence is "contact is added to audience" or "tag is applied to contact."

The correct architecture for this use case:

CF7 submission
    |
    v
Add contact to Mailchimp audience via API
    |
    v
Apply specific tag (e.g. "contact-form-inquiry")
    |
    v
Mailchimp automation triggers on tag applied
    |
    v
Drip email 1 sent immediately
    |
    v (7 days later)
Drip email 2 sent

The tag is the trigger, not the audience membership alone. This lets you have one audience with multiple automations triggered by different tags from different forms.

Implementation: Three Approaches

Approach 1: MC4WP Plugin + Code Snippet (What the Forum Suggested)

The MC4WP plugin connects CF7 to Mailchimp. By default it shows a checkbox. To remove the checkbox and subscribe silently, add a tag based on which form was submitted:

// Add to functions.php
// Source: ibericode/mailchimp-for-wordpress sample snippets

add_filter('mc4wp_integration_cf7_tags', function($tags, $form) {
    // Apply different tags based on form ID
    $form_tag_map = [
        123 => ['contact-form-inquiry'],    // replace with your form IDs
        456 => ['quote-request'],
        789 => ['newsletter-signup'],
    ];

    $form_id = (int) $form->id();

    if (isset($form_tag_map[$form_id])) {
        $tags = array_merge($tags, $form_tag_map[$form_id]);
    }

    return $tags;
}, 10, 2);

For silent subscription (no checkbox), configure MC4WP's CF7 integration with "Implicit sign-up" enabled in the plugin settings. This subscribes the contact on every form submission without showing a UI element.

Limitation: MC4WP's implicit signup adds contacts to whichever audience you configure globally. If you need different audiences per form, you need the approach below.

Approach 2: Direct Mailchimp API Call from CF7 Hook

This gives full control: which audience, which tags, which status, per form. No MC4WP required.

add_action('wpcf7_before_send_mail', 'cf7_to_mailchimp_silent');

function cf7_to_mailchimp_silent($contact_form) {
    $form_id = (int) $contact_form->id();

    // Map form IDs to Mailchimp audience IDs and tags
    $form_config = [
        123 => [
            'audience_id' => 'abc123def4',   // your Mailchimp audience/list ID
            'tags'        => ['contact-form-inquiry'],
        ],
        456 => [
            'audience_id' => 'abc123def4',
            'tags'        => ['quote-request'],
        ],
    ];

    if (!isset($form_config[$form_id])) return;

    $config      = $form_config[$form_id];
    $submission  = WPCF7_Submission::get_instance();
    if (!$submission) return;

    $data        = $submission->get_posted_data();
    $email       = sanitize_email($data['your-email'] ?? '');
    $name_parts  = explode(' ', sanitize_text_field($data['your-name'] ?? ''), 2);
    $first_name  = $name_parts[0] ?? '';
    $last_name   = $name_parts[1] ?? '';

    if (empty($email)) return;

    $api_key     = defined('MAILCHIMP_API_KEY') ? MAILCHIMP_API_KEY : '';
    $server      = substr($api_key, strpos($api_key, '-') + 1); // e.g. "us21"
    $audience_id = $config['audience_id'];
    $member_hash = md5(strtolower($email));

    // Add or update the contact (PUT is idempotent - updates if exists)
    $response = wp_remote_request(
        "https://{$server}.api.mailchimp.com/3.0/lists/{$audience_id}/members/{$member_hash}",
        [
            'method'  => 'PUT',
            'headers' => [
                'Authorization' => 'Basic ' . base64_encode('anystring:' . $api_key),
                'Content-Type'  => 'application/json',
            ],
            'body'    => wp_json_encode([
                'email_address' => $email,
                'status_if_new' => 'subscribed',  // only sets status for NEW contacts
                'merge_fields'  => [
                    'FNAME' => $first_name,
                    'LNAME' => $last_name,
                ],
            ]),
            'timeout' => 15,
        ]
    );

    if (is_wp_error($response)) {
        error_log('[CF7->Mailchimp] Member upsert failed: ' . $response->get_error_message());
        return;
    }

    $status_code = wp_remote_retrieve_response_code($response);
    if ($status_code >= 400) {
        error_log('[CF7->Mailchimp] API error ' . $status_code . ': ' . wp_remote_retrieve_body($response));
        return;
    }

    // Apply tags separately (tag endpoint accepts array of tag operations)
    $tags_payload = array_map(fn($tag) => ['name' => $tag, 'status' => 'active'], $config['tags']);

    wp_remote_post(
        "https://{$server}.api.mailchimp.com/3.0/lists/{$audience_id}/members/{$member_hash}/tags",
        [
            'headers' => [
                'Authorization' => 'Basic ' . base64_encode('anystring:' . $api_key),
                'Content-Type'  => 'application/json',
            ],
            'body'    => wp_json_encode(['tags' => $tags_payload]),
            'timeout' => 15,
        ]
    );
}

Store your API key in wp-config.php:

define('MAILCHIMP_API_KEY', 'your-key-here-us21');

Key decisions in this code:

PUT to the member endpoint instead of POST. PUT is idempotent: if the contact already exists, it updates them. POST on an existing contact returns a 400 error. Using PUT prevents duplicates.
status_if_new: subscribed sets the status only for brand-new contacts. It does not change an existing contact's subscription status (so someone who previously unsubscribed stays unsubscribed).
Tags are applied in a separate API call via the /tags endpoint because the main PUT endpoint does not accept tag modifications directly.
member_hash is md5(lowercase email), which is how Mailchimp identifies members in its API.

Approach 3: Contact Form to API Plugin

Contact Form to API handles the Mailchimp API call from a configuration UI. Set the Mailchimp audience endpoint, configure the Authorization header with your API key, and map CF7 fields to the Mailchimp payload. No PHP deployment required, and the field mapping updates happen in the WordPress dashboard when form fields change.

Setting Up the Mailchimp Automation to Trigger on Tag

Once contacts are being added and tagged, configure the Mailchimp automation:

Go to Automations > Customer Journeys
Click Create Journey
Set the starting point to "Tag is added"
Select the tag you are applying from CF7 (e.g. contact-form-inquiry)
Add your email steps with delays between them (e.g. immediate email, then one week later)
Activate the journey

When CF7 applies the tag to a new contact, Mailchimp's automation fires immediately.

Important: the automation only fires for contacts who receive the tag while the journey is active. Contacts tagged before the journey was activated do not enter the journey retroactively.

Audience ID: Where to Find It

The audience ID is not the same as the audience name. Find it at:

Mailchimp > Audience > Manage Audience > Settings > Audience name and defaults

The ID is shown in the URL and in the settings panel. It looks like abc123def4 (10 characters, alphanumeric).

Why Contact Form 7 Breaks on Static Sites (And What to Do About It)

Rahul Sharma — Thu, 04 Jun 2026 14:02:20 +0000

A developer posted this on the WordPress support forums:

"When we deploy to our live instance, the form is not working and gives a JSON error. This path has a 404 not found error: /wp-json/contact-form-7/v1/contact-forms/978/feedback/schema"

They were using Simply Static to export their WordPress site to static files and deploying the output to a live host. The plugin author's reply pointed to a CORS issue. The developer pushed back. The thread went unresolved for weeks before being closed with "please contact Pro support."

The actual problem is more fundamental than CORS. Contact Form 7 is a dynamic plugin. It processes form submissions via a WordPress REST API endpoint. When you export a WordPress site to static HTML, that REST API does not exist on the static host. You cannot fix this with a CORS header. You need to rearchitect how the form submits.

What Is Actually Happening

When a user fills out a CF7 form and clicks submit, CF7's JavaScript sends a POST request to:

POST /wp-json/contact-form-7/v1/contact-forms/{form_id}/feedback

This endpoint is registered by the CF7 plugin and handled by PHP running on your WordPress server. It validates the submission, sends the email, and returns a JSON response that CF7's JS uses to show the success or error message.

On a static site deployment, there is no PHP. There is no WordPress. There is no REST API. The URL /wp-json/contact-form-7/v1/contact-forms/978/feedback simply does not exist on the static host. The browser gets a 404.

The /feedback/schema 404 the developer saw is CF7 pre-fetching the form's validation schema before submission. That 404 is a symptom, not the root cause. The root cause is that the entire CF7 PHP backend is missing on the static host.

The Three Specific Failures in This Thread

Failure 1: REST API Endpoint Returns 404

/wp-json/contact-form-7/v1/contact-forms/978/feedback/schema
404 Not Found

No PHP runtime on the static host means no WordPress REST API. Every request to /wp-json/ returns 404. This cannot be fixed by configuring Simply Static differently because there is nothing to copy. The endpoint is not a file, it is a dynamic PHP route.

Failure 2: Plugin JS Asset Not Readable

The developer found this in Simply Static's diagnostic output:

/var/www/html/wp-content/plugins/simply-static-pro/assets/ssp-form-webhook-public.js
Status: Not readable

This JavaScript file handles CF7's form submission flow on the static site. Simply Static Pro replaces CF7's default AJAX submission with a webhook-based flow specifically to work around the REST API problem. If this file has incorrect permissions (not world-readable), the static export cannot include it and the form falls back to the broken default behavior.

Fix for this specific issue:

chmod 644 /var/www/html/wp-content/plugins/simply-static-pro/assets/ssp-form-webhook-public.js

Then re-run the Simply Static export.

Failure 3: CORS Error in Browser Console

The plugin author diagnosed a CORS issue. This is partially correct but only as a secondary problem.

If Simply Static Pro is configured to proxy CF7 submissions to a webhook on a different domain from the static site, the browser enforces CORS policy on that cross-origin request. The static site is on static-domain.com, the webhook receiver is on wp-domain.com, the browser blocks the request.

The CORS error in the browser console looks like:

Access to fetch at 'https://wp-domain.com/wp-json/contact-form-7/...'
from origin 'https://static-domain.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

To add CORS headers to your WordPress origin, add this to your .htaccess on the WordPress server (not the static host):

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "https://static-domain.com"
    Header set Access-Control-Allow-Methods "POST, GET, OPTIONS"
    Header set Access-Control-Allow-Headers "Content-Type"
</IfModule>

Or programmatically in WordPress:

add_action('rest_api_init', function() {
    remove_filter('rest_pre_serve_request', 'rest_send_cors_headers');
    add_filter('rest_pre_serve_request', function($value) {
        $origin = get_http_origin();
        $allowed = ['https://static-domain.com'];

        if (in_array($origin, $allowed)) {
            header('Access-Control-Allow-Origin: ' . $origin);
            header('Access-Control-Allow-Methods: POST, GET, OPTIONS');
            header('Access-Control-Allow-Headers: Content-Type');
        }
        return $value;
    });
});

This only resolves CORS. It does not fix the 404 unless your WordPress installation is still running and accessible at the origin URL.

The Two Architectures for CF7 on Static Sites

There are two patterns that actually work. Everything else is a workaround for a mismatched architecture.

Pattern 1: Keep WordPress Running as the Form Backend

Your static site is served from a CDN or static host. Your WordPress installation stays live at a separate URL (e.g., api.yourdomain.com or a subdomain). CF7 submits to the live WordPress REST API on that subdomain.

Requirements:

WordPress must remain running and publicly accessible
CORS headers must be configured on the WordPress origin to allow requests from your static domain
The form action in the CF7 JS must point to the correct WordPress URL

This is what Simply Static Pro's webhook configuration enables when working correctly.

Pattern 2: Replace CF7 with a Third-Party Form Endpoint

Remove the CF7 REST API dependency entirely. Use a form backend service that accepts POST submissions directly from a static HTML form without requiring a PHP backend.

Options:

Formspree, Netlify Forms, Getform (managed form endpoints)
A webhook receiver you control (your own API, n8n, Make)
Contact Form to API configured to forward submissions to an external endpoint before the static export

If your form needs to reach a CRM or send an email, Contact Form to API can handle that forwarding from within WordPress during the submission event, before Simply Static exports the site. The static site only needs to trigger the submission. The WordPress plugin processes and forwards it while WordPress is still the active runtime.

Diagnostic Steps for CF7 on a Static Site

Step 1: Confirm whether your WordPress backend is still running

Open your browser and go to https://yourwordpressurl.com/wp-json/. If you get a JSON object describing the REST API, WordPress is live. If you get a 404 or your static site's 404 page, the WordPress PHP backend is gone.

Step 2: Check the browser console on form submission

Open DevTools (F12), go to the Console tab, and submit the form. You will see one of:

404 Not Found on the feedback endpoint - WordPress REST API is not reachable
CORS error - WordPress is reachable but blocking cross-origin requests
net::ERR_CONNECTION_REFUSED - WordPress server is offline or not accessible

Step 3: Verify the forms.json configuration

Simply Static Pro stores form routing config at:

/wp-content/uploads/simply-static/configs/forms.json

A correctly configured entry looks like:

[{
  "id": "978",
  "tool": "cf7",
  "endpoint": "https://your-wordpress-url.com/?mailme",
  "redirect_url": ""
}]

If endpoint points to your static domain instead of your WordPress domain, submissions will never reach the PHP backend.

Step 4: Check JS asset file permissions

ls -la /var/www/html/wp-content/plugins/simply-static-pro/assets/ssp-form-webhook-public.js

The file needs to be readable by the web server user (typically www-data on Ubuntu/Debian). If permissions are 600 or owned by root, the file is not readable during the export process.

TL;DR

CF7 on a static site breaks because CF7 needs PHP to process submissions. Static sites have no PHP. The 404 on /wp-json/contact-form-7/v1/contact-forms/978/feedback/schema is not a file missing from the export. It is a REST API route that cannot exist without WordPress running.

The CORS diagnosis was correct as a secondary issue but missed the primary one. You cannot CORS-header your way around a missing PHP backend.

Fixes in order of reliability:

Keep WordPress running at a subdomain as the form backend, configure CORS headers
Fix the Simply Static Pro JS asset permissions and correct forms.json endpoint URL
Replace the CF7 REST API dependency with a direct external API using Contact Form to API before the static export

CF7 Says "null" on Zoho Flow Connection: mod_security, REST API Locks, and Host Blocks Explained

Rahul Sharma — Fri, 29 May 2026 13:33:04 +0000

"/>
A developer posted this on the WordPress support forums:

"Was able to create the API in WordPress, but the Zoho Flow app registration screen is getting Contact Form 7 says 'null' as an error."

Seven replies later, the resolution was: "The issue has been resolved, it was related to the hosting provider."

That tells you nothing. Three completely different server-level problems were identified in that thread, each producing the same symptom: a null or broken response when Zoho Flow tries to read your CF7 forms during the connection setup. This post breaks down each one, how to identify which you are hitting, and how to fix it.

What "null" Actually Means in This Context

When Zoho Flow connects to your WordPress site, it calls a REST API endpoint registered by the Zoho Flow plugin to fetch a list of your CF7 forms:

GET /wp-json/zoho-flow/contact-form-7/v1/forms

If something intercepts that request before it reaches the plugin, Zoho Flow receives a malformed or empty response, which surfaces as "null" or a generic error in the Zoho Flow UI. The connection appears to fail, but the failure is happening at a layer completely below the plugin.

Three things intercept this request in the thread:

mod_security blocking the keyword "contact" in the API path
A REST API lockdown plugin requiring authentication
A hosting provider level block

Cause 1: mod_security Blocking "contact" in the API Path

This was Zoho Flow's first diagnosis in the thread. The actual API response they received was:

<script>document.cookie = "humans_21909=1"; document.location.reload(true)</script>

This is not a PHP error. It is a bot-challenge response injected by a Web Application Firewall (WAF), specifically Apache mod_security or a similar layer. The WAF detected a pattern in the request (the word "contact" in the path /zoho-flow/contact-form-7/v1/forms) and flagged it as potentially malicious, returning a bot-challenge instead of passing the request through to WordPress.

The Zoho Flow plugin never even receives this request. WordPress never sees it. The challenge script is the server's response, not WordPress's.

Why "contact" triggers it:

mod_security rule sets (particularly OWASP CRS) include rules that flag certain keywords in URL paths and query strings that are commonly associated with spam bots and form abuse. "contact-form" in an API path can trip these rules depending on the active ruleset version and configuration.

How to confirm this is your issue:

Check the response your server sends to that endpoint. From a terminal or Postman:

curl -v "https://yoursite.com/wp-json/zoho-flow/contact-form-7/v1/forms"

If the response body contains document.cookie or document.location.reload, mod_security is intercepting the request.

How to fix it:

Option A: Ask your hosting provider to whitelist the path /wp-json/zoho-flow/contact-form-7/ in their mod_security configuration. This is a standard hosting support request on dedicated or VPS servers.

Option B: If you have server access, add a mod_security exception in your .htaccess or Apache virtual host config:

<LocationMatch "/wp-json/zoho-flow/contact-form-7/">
    SecRuleEngine Off
</LocationMatch>

On Nginx with ModSecurity:

location ~ ^/wp-json/zoho-flow/contact-form-7/ {
    ModSecurityEnabled off;
    # ... rest of your location block
}

Option C: Switch to a direct CF7-to-Zoho integration that does not register a REST API endpoint, removing the path that triggers mod_security entirely. Covered at the end of this post.

Cause 2: REST API Locked Down by a Security Plugin

The developer in the thread then tested the endpoint in Postman and got a different error:

{
  "code": "rest_cannot_access",
  "message": "DRA: Only authenticated users can access the REST API.",
  "data": { "status": 401 }
}

The prefix DRA: identifies this as coming from the "Disable REST API" plugin (or a similar plugin such as "WP Hide & Security Enhancer"). This plugin blocks all unauthenticated REST API requests, returning a 401 before any registered route handler runs.

When Zoho Flow tries to read your CF7 forms via the REST API, it is making an unauthenticated GET request. A REST API lockdown plugin blocks this before the Zoho Flow plugin ever sees it.

How to confirm:

Look for these plugins in your WordPress admin under Plugins > Installed Plugins:

Disable REST API
WP Hide and Security Enhancer
Perfmatters (has a "Disable REST API" option)
iThemes Security (has REST API restrictions)
All In One WP Security (has REST API options)

Check each one for a setting that restricts REST API access to logged-in users.

How to fix it:

Option A: Add the Zoho Flow route to the plugin's allowlist. Most REST API restriction plugins have a whitelist field where you can specify paths to exempt. Add:

/wp-json/zoho-flow/

Option B: Temporarily disable the REST API restriction plugin, complete the Zoho Flow connection setup, then re-enable it. This works if the restriction only affects the connection setup step and not the live webhook trigger path.

Option C: Configure the restriction plugin to only block REST API access from the frontend (non-admin requests) rather than all unauthenticated requests globally. This is usually a setting in the plugin's options.

Cause 3: Hosting Provider Level Block

The final resolution in the thread was "related to the hosting provider." This is the least diagnosable from your end because the block can happen at multiple layers that you do not control:

Shared hosting WAF rules (different from mod_security, often proprietary)
Load balancer or reverse proxy rules
Cloudflare or similar CDN firewall rules
Country-based IP filtering blocking Zoho Flow's server IPs

How to identify this:

If you have ruled out mod_security and REST API restriction plugins, and the endpoint still returns a non-WordPress response, check:

curl -I "https://yoursite.com/wp-json/zoho-flow/contact-form-7/v1/forms"

Check the response headers. If you see cf-ray headers, the request is going through Cloudflare. A Cloudflare WAF rule may be blocking it. If you see non-standard server headers that do not match your known stack, a hosting-level proxy is involved.

For Cloudflare specifically: check Security > WAF > Firewall Events in your Cloudflare dashboard for blocked requests to that path around the time of your test.

How to fix it:

Contact your hosting provider with the specific API path and response you are receiving. Give them:

The endpoint: /wp-json/zoho-flow/contact-form-7/v1/forms
The HTTP method: GET
The response status code and body you receive
The time of your test request (helps them check their firewall logs)

Identifying Which Cause You Are Hitting

Run this sequence before contacting anyone:

Step 1: Test the endpoint directly with curl:

curl -v "https://yoursite.com/wp-json/zoho-flow/contact-form-7/v1/forms"

Response	Cause
`<script>document.cookie...`	mod_security WAF challenge
`{"code":"rest_cannot_access"...}`	REST API lockdown plugin
`{"code":"rest_no_route"...}`	Zoho Flow plugin not active or not registered
Connection timeout or refused	Server or network level block
Valid JSON array of forms	Integration should work, problem is elsewhere

Step 2: Check whether other WordPress REST API routes work:

curl "https://yoursite.com/wp-json/wp/v2/posts"

If this also returns a 401 or bot-challenge, the block is global (REST API restriction plugin or WAF). If this returns posts normally but the Zoho Flow route fails, the block is path-specific (mod_security keyword rule).

Step 3: Test from a different IP or network. If it works from your local machine but fails when Zoho Flow's servers call it, the block is IP-based on the server side.

The Alternative: Skip the REST API Dependency Entirely

All three causes in this thread exist because Zoho Flow's connection setup requires an unauthenticated REST API call to your WordPress site. Any server security layer that touches that request path can break it.

Contact Form to API takes the opposite architectural approach: the plugin makes outbound requests from WordPress to your destination API (Zoho CRM, etc.) rather than requiring Zoho to make inbound requests to WordPress. This removes the inbound REST API dependency and the entire class of problems above. There is no API path for mod_security to block, no REST API lockdown plugin to route around, and no hosting provider firewall to negotiate with.

Summary

All three problems produce the same symptom: "null" or broken response during Zoho Flow connection setup. The diagnostic step that separates them is a direct curl call to the endpoint with verbose output.

Cause	Response you see	Fix
mod_security keyword block	HTML script bot-challenge	Whitelist path in mod_security config or ask host
REST API lockdown plugin	`rest_cannot_access` 401 JSON	Whitelist route in plugin settings
Hosting provider block	Timeout, non-standard response, or CDN block	Contact host with path and response details

DEV Community: Rahul Sharma

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

How to Find the Correct Field Names

Testing Your Field Names Before Connecting CF7

Sending Static Values Alongside Form Fields

Quick Checklist When You Get a 400 Response

How to Connect Contact Form 7 to Monday.com CRM

Why CF7 Does Not Connect to Monday.com Out of the Box

How Monday.com Receives Data from External Sources

Option 1: Use Contact Form to API (Easiest, No Code)

Option 2: Webhook Approach (More Setup, More Fragile)

Option 3: Custom PHP Code

Which Approach Is Right for You

CF7 Webhook Throwing a 500 Error? Checkboxes and Acceptance Fields Are Probably the Cause

What Is Actually Going Wrong

Which Field Types Trigger This Error

The Quick Fix If You Must Keep Using CF7 Apps Webhook

The Better Fix: Use a Plugin That Handles Arrays Properly From the Start

Why This Keeps Happening With CF7 Webhooks

What to Check If You Are Seeing a 500 Error

CF7 File Uploads: Why the Attachment Never Arrives in Your Email

The Three Places the File Tag Goes (And What Each One Does)

Placement 1: The Form Tab

Placement 2: The Mail Tab Body

Placement 3: The Mail Tab File Attachments Field

Step by Step: Correct CF7 File Upload Configuration

Step 1: Form Tab

Step 2: Mail Tab Body (Optional)

Step 3: Mail Tab File Attachments Field (Required for Attachment)

The Filetypes Wildcard Problem

Where Uploaded Files Actually Go

Making Fields Optional

Quick Reference

How to Use a CF7 Field to Query an External API and Populate Other Fields

Why You Need a Server-Side Proxy

Step 1: Register the WordPress AJAX Endpoint

Step 2: Pass the Nonce to JavaScript

Step 3: The JavaScript

What the 600ms Debounce Does

Making Populated Fields Required in CF7

Using Contact Form to API for the Submission Side

Quick Checklist

"Invalid OAuth2 Access Token" in CF7 Google Sheets Connector: What the Stack Trace Actually Tells You

Reading the Stack Trace

Three Causes of "Invalid OAuth2 Access Token"

Cause 1: Google OAuth Token Expired (Most Common)

Cause 2: Google Client Library Version Conflict

Cause 3: Wrong Google Account or Revoked Access

Verifying the Token State Without the Plugin

Checking Google Cloud Console OAuth App Status

The Direct API Alternative

Diagnosis Checklist

Why CF7 Plugin Settings Stop Saving After a CF7 Update (And How to Fix It)

What Changed in CF7 5.5.x

Why Settings Appear to Save But Do Not

The Correct Pattern for CF7 Add-On Settings That Survive Version Changes

Storing API Credentials: get_option vs wp-config.php

Basic Auth: What It Is and When It Is Acceptable

Diagnosing Settings That Do Not Save

The Real Fix vs Rolling Back

Why CF7 Plugin Settings Stop Saving After a CF7 Update (And How to Fix It)

What Changed in CF7 5.5.x

Why Settings Appear to Save But Do Not

The Correct Pattern for CF7 Add-On Settings That Survive Version Changes

Storing API Credentials: get_option vs wp-config.php

Basic Auth: What It Is and When It Is Acceptable

Diagnosing Settings That Do Not Save

The Real Fix vs Rolling Back

How to Trigger a Mailchimp Drip Sequence from a CF7 Form (Without a Checkbox)

What the Developer Is Actually Trying to Build

The Consent Question: Can You Silent-Subscribe Someone?

Error 1: `invalid_grant` on the OAuth Token Endpoint

Error 2: `403 Forbidden: email not allowed`

Error 3: `400 Bad Request: duplicate address`

Storing API Credentials: `get_option` vs `wp-config.php`

Storing API Credentials: `get_option` vs `wp-config.php`