DEV Community

Rahul Sharma
Rahul Sharma

Posted on

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

#wordpress #zoho #security #api

CF7 Says "/>
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
Enter fullscreen mode Exit fullscreen mode

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:

  1. mod_security blocking the keyword "contact" in the API path
  2. A REST API lockdown plugin requiring authentication
  3. 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>
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

On Nginx with ModSecurity:

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

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 }
}
Enter fullscreen mode Exit fullscreen mode

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/
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode
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"
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)