DEV Community: Rahul Sharma

CF7 to Trello: Cards Not Being Created Every Cause Explained

Rahul Sharma — Thu, 10 Sep 2026 06:30:07 +0000

Trello is one of the simplest project management tools and its API is one of the most straightforward to call. Yet CF7 to Trello integrations fail constantly, usually for the same handful of reasons that are never clearly documented anywhere.

This post covers every cause of CF7 submissions not creating Trello cards, with direct API calls you can use to verify each piece before connecting your form.

Cause 1: API Key and Token Confusion

Trello uses a two-part authentication system that trips up most developers on first setup.

You need two separate values:

API Key: Found at trello.com/power-ups/admin after creating a Power-Up. This is your application identifier.
API Token: Generated separately by authorising your Power-Up to access your Trello account. This is the user-level access grant.

The API Key alone cannot make API calls. The Token alone cannot make API calls. Both are required on every request.

The correct API call format is:

https://api.trello.com/1/cards?key=YOUR_API_KEY&token=YOUR_TOKEN

Or as headers:

curl -X POST "https://api.trello.com/1/cards" \
  -H "Accept: application/json" \
  -d "key=YOUR_API_KEY" \
  -d "token=YOUR_TOKEN" \
  -d "idList=YOUR_LIST_ID" \
  -d "name=Test Card from CF7" \
  -d "desc=This is a test submission"

If either value is missing or swapped, Trello returns invalid key or invalid token.

How to generate a token: After generating your API Key, go to:

https://trello.com/1/authorize?expiration=never&scope=read,write&response_type=token&name=CF7+Integration&key=YOUR_API_KEY

Replace YOUR_API_KEY with your actual key. Authorise and copy the token from the resulting page.

Cause 2: Using Board ID Instead of List ID

Cards in Trello are created inside Lists, not inside Boards. The API endpoint for creating a card requires a List ID (idList), not a Board ID.

Board IDs and List IDs look identical — both are 24-character alphanumeric strings. This is where most configuration errors happen. The plugin asks for a List ID. The user looks up their Board URL, copies the Board ID, and pastes it in. The API returns invalid id or creates nothing.

Find your List ID:

# Get all lists on a board
curl "https://api.trello.com/1/boards/YOUR_BOARD_ID/lists?key=YOUR_API_KEY&token=YOUR_TOKEN"

Each list in the response has an id field. That 24-character string is what goes in the idList parameter when creating a card.

Find your Board ID from the board URL: trello.com/b/BOARD_ID/board-name. The short code after /b/ is not the full ID. To get the full Board ID:

curl "https://api.trello.com/1/members/me/boards?key=YOUR_API_KEY&token=YOUR_TOKEN&fields=id,name"

Cause 3: The Card Description Can Only Hold One Mapped Field in Free Plugins

Unlike ClickUp which has custom fields, Trello cards have a limited structure: Name, Description, Labels, Due Date, and Members. Most CF7 to Trello integrations map form data to the card Name and Description.

The Description field in Trello accepts plain text or Markdown. If your form has multiple fields (name, email, phone, message), you need to concatenate them into a single Description string.

Many free CF7 Trello plugins only allow mapping one CF7 field to the Description. If you have a form with five fields, four of them go nowhere. The card is created with just the name and one field value.

The correct approach when using the Trello API directly is to build the description as a multi-line string:

{
  "idList": "YOUR_LIST_ID",
  "name": "Enquiry from [your-name]",
  "desc": "**Name:** [your-name]\n**Email:** [your-email]\n**Phone:** [your-phone]\n**Message:** [your-message]"
}

Trello renders Markdown in card descriptions, so **Name:** renders as bold in the Trello UI.

Cause 4: Token Expired or Insufficient Scope

When generating the Trello token, you choose an expiration and scope. If the expiration was set to 30 days and it has now been more than 30 days since setup, the token has expired. Every API call returns invalid token.

The scope must include write to create cards. A token generated with scope=read can fetch board and list data but cannot create, update, or delete anything.

Always generate tokens with:

expiration=never for server integrations
scope=read,write

If your existing token has expired or has read-only scope, generate a new one using the URL in Cause 1 above.

Connecting CF7 to Trello Directly

Trello's card creation API is genuinely one of the simplest in the project management space. You do not need a dedicated plugin. Contact Form to API handles the POST request from the WordPress dashboard.

Configure:

Endpoint: https://api.trello.com/1/cards
Method: POST
Body:

{
  "key": "YOUR_API_KEY",
  "token": "YOUR_TOKEN",
  "idList": "YOUR_LIST_ID",
  "name": "Enquiry from [your-name]",
  "desc": "**Email:** [your-email]\n**Phone:** [your-phone]\n**Message:** [your-message]"
}

Every CF7 field in brackets gets replaced with the actual submitted value before the request is sent. The response log shows you whether Trello created the card and what the card ID is.

Quick Diagnosis

# 1. Test your API key and token
curl "https://api.trello.com/1/members/me?key=YOUR_KEY&token=YOUR_TOKEN"
# Expect: your Trello user object
# "invalid key" = API key wrong
# "invalid token" = token wrong, expired, or wrong scope

# 2. Get your board's lists to find List IDs
curl "https://api.trello.com/1/boards/YOUR_BOARD_ID/lists?key=YOUR_KEY&token=YOUR_TOKEN"

# 3. Create a test card
curl -X POST "https://api.trello.com/1/cards?key=YOUR_KEY&token=YOUR_TOKEN&idList=YOUR_LIST_ID&name=Test+Card"
# Expect: card object with "id" field
# "invalid id" = wrong List ID (possibly using Board ID instead)

Symptom	Cause	Fix
`invalid key`	Wrong API key	Get key from `trello.com/power-ups/admin`
`invalid token`	Token wrong, expired, or read-only	Regenerate with `expiration=never&scope=read,write`
`invalid id` on card creation	Board ID used instead of List ID	Fetch lists from board, use the list `id`
Card created but only has name	Free plugin limitation on description	Use direct API with multi-field description string
Cards stopped being created	Token expired	Check token age, regenerate if past expiration

CF7 to ClickUp Tasks Not Being Created - Four Causes and How to Fix Each

Rahul Sharma — Wed, 09 Sep 2026 11:19:53 +0000

You connected Contact Form 7 to ClickUp using an integration plugin. You set up the task creation. You tested the form. Nothing appeared in ClickUp.

Or maybe it was working, you added a new field to your form, and now the integration fails every time with an error about an invalid field value.

Both situations happen constantly with CF7 to ClickUp integrations. Here is what is actually going wrong in each case.

Cause 1: Field Type Mismatch - the `FIELD_010` Error

This was the exact error in a WordPress support forum thread:

{"err": "Value is not a valid URL", "ECODE": "FIELD_010"}

The developer had added a new field to their WordPress form and mapped it to a ClickUp custom field. The problem: the ClickUp field was configured as a URL type. The CF7 field was a plain text field. When the integration sent a text value to a URL custom field, ClickUp rejected it with FIELD_010.

ClickUp has strict type validation on custom fields. If you map a CF7 text field to a ClickUp Number field, a URL field, or a Date field, ClickUp will reject the value silently or with the FIELD_010 error depending on your plugin's error handling.

How to check: In ClickUp, open the List where tasks are being created and look at the custom fields. Each field has a type icon next to the name (text, number, URL, date, email, etc.). Match your CF7 field type to the ClickUp custom field type exactly. For most form fields, ClickUp's "Text" custom field type is the safest destination.

Cause 2: Wrong Location in ClickUp's Four-Level Hierarchy

ClickUp organises work in four nested levels: Workspace → Space → Folder → List. Tasks are created inside Lists. When setting up a CF7 to ClickUp integration, you must select all four levels correctly before the plugin knows where to create the task.

The most common mistake: selecting the Space or Folder instead of the List. Tasks cannot be created at the Space or Folder level in ClickUp's API. If your plugin is trying to create a task at the wrong level, the API returns an error that the plugin may swallow silently.

A second common mistake: the List ID in your plugin settings is stale. If you renamed or moved the List in ClickUp after setting up the integration, the plugin may still be pointing at the old List ID, which either no longer exists or has been reassigned.

Verify your List ID: In ClickUp, open the List you want tasks created in. Click the three dots menu on the List name and select "Copy Link." The URL contains the List ID. Compare this against what is stored in your plugin settings.

Cause 3: ClickUp API Token vs OAuth - Scope Issues

ClickUp has two ways to authenticate:

Personal API Token: Found in ClickUp under Settings → Apps → API Token. This token has full access to everything the account owner can access. Simple, works for personal use.

OAuth App Token: Generated through a ClickUp app registration. Requires selecting specific scopes (task:write, list:read, etc.) when the app is created.

Most CF7 integration plugins use the personal API token. If your plugin uses OAuth (either its own OAuth app or a third-party service), the token may not have the task:write scope enabled. The API call authenticates successfully but ClickUp rejects the task creation because the token lacks permission to write tasks.

How to confirm: Use the personal API token approach wherever your plugin offers a choice. Test it directly:

curl -X GET "https://api.clickup.com/api/v2/user" \
  -H "Authorization: YOUR_PERSONAL_API_TOKEN"

If you see your user details, the token is valid and has basic access. Then test task creation specifically:

curl -X POST "https://api.clickup.com/api/v2/list/YOUR_LIST_ID/task" \
  -H "Authorization: YOUR_PERSONAL_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Test Task from CF7",
    "description": "This is a test"
  }'

A 200 response with a task object confirms your token, List ID, and permissions are all correct.

Cause 4: Custom Fields Locked Behind a Pro Paywall

If your integration is creating tasks in ClickUp but the custom field values are not being populated, check whether your plugin requires a Pro upgrade for custom field support.

The Advanced Form Integration plugin's ClickUp documentation states explicitly: "Requires a Pro license to add tags and custom fields." Free plan users can create tasks with a name and description, but mapping CF7 form fields to ClickUp custom fields requires the paid version.

This produces a confusing situation: the integration appears to work (tasks are created), but most of the form data never makes it into ClickUp because it was mapped to custom fields that the free plugin version does not send.

If this is your situation, either upgrade the plugin or switch to a direct API integration where you control exactly which custom fields receive which values.

Connecting CF7 to ClickUp Directly

ClickUp's API for creating a task with custom fields:

POST https://api.clickup.com/api/v2/list/{list_id}/task
Authorization: YOUR_PERSONAL_API_TOKEN
Content-Type: application/json

{
  "name": "Enquiry from Jane Smith",
  "description": "Email: jane@example.com\nMessage: Their message here",
  "custom_fields": [
    {
      "id": "CUSTOM_FIELD_ID",
      "value": "jane@example.com"
    }
  ]
}

Get your custom field IDs:

curl "https://api.clickup.com/api/v2/list/YOUR_LIST_ID/field" \
  -H "Authorization: YOUR_PERSONAL_API_TOKEN"

Each field object has an id property — that is what you pass in custom_fields[].id.

Contact Form to API handles this direct API call from the WordPress dashboard. You set the ClickUp task creation endpoint, add your personal API token as the Authorization header, and define the JSON body mapping your CF7 fields to ClickUp's expected structure. Custom fields, tags, assignees all controlled from your settings without a Pro paywall gate on basic field mapping.

Quick Diagnosis

Symptom	Most Likely Cause
`FIELD_010` error in logs	CF7 field type does not match ClickUp custom field type
Tasks created but no custom field data	Plugin free tier does not send custom fields
No tasks created, no error	Wrong List selected (Space or Folder chosen instead)
Tasks created pointing to old List	List was renamed/moved after setup — List ID is stale
401 authentication error	API token invalid or OAuth scopes insufficient

CF7 to Slack Notifications Not Working - What Is Actually Broken

Rahul Sharma — Tue, 08 Sep 2026 07:31:45 +0000

Your team set up CF7 to send a Slack message every time someone fills in the contact form. It worked for a while. Then one day the notifications stopped. Or maybe you are setting it up fresh and the Slack channel is completely silent even after the form submits successfully.

There are four reasons this happens. Three of them have nothing to do with your CF7 configuration.

Reason 1: You Are Using a Legacy Slack Webhook URL

Slack has two types of incoming webhooks and they are not interchangeable.

Legacy Incoming Webhooks were created before Slack apps existed. They look like:

https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

App-based Incoming Webhooks are the current supported method. They look identical in format but are generated through a Slack App in your workspace.

Slack stopped creating new legacy webhooks years ago and has been progressively deprecating them. If your webhook URL was generated more than a few years ago through the old "Incoming Webhooks" configuration in Slack settings (not through an app), it may have stopped working without any notification.

How to confirm: Send a test POST to your webhook URL directly:

curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"Test from WordPress"}' \
  YOUR_WEBHOOK_URL

If you get invalid_token or no_service in the response, the webhook is retired. If you get ok, the webhook is still active.

Fix: Create a fresh Slack App and generate a new webhook:

Go to api.slack.com/apps
Click "Create New App" → "From scratch"
Name it something like "WordPress CF7 Alerts"
Under "Add features and functionality", choose "Incoming Webhooks"
Toggle "Activate Incoming Webhooks" to On
Click "Add New Webhook to Workspace"
Choose the channel and click Allow
Copy the new webhook URL

Update this URL in your CF7 Slack plugin settings or in your custom code.

Reason 2: The Dedicated Plugin Is Abandoned

Most CF7 to Slack plugins on WordPress.org were last updated years ago. The "Slack Contact Form 7" plugin's most recent support thread reported it not working in WordPress 5.8 — with zero replies from the plugin author. That was in 2021. The plugin has not been updated since.

An abandoned plugin that hooks into CF7's submission process will break silently when CF7 or WordPress updates change the internal hooks the plugin relies on. The form submits. The plugin fires. Something in the hook chain fails. No Slack message arrives. No error appears anywhere.

If you are using a dedicated CF7 Slack plugin, check its last updated date in your WordPress admin. If it has not been updated in the past year, it is almost certainly running against outdated CF7 internals.

Reason 3: The Webhook URL Is Correct But the Payload Format Is Wrong

Slack's Incoming Webhooks API has evolved. The original format sent a simple text field:

{"text": "New form submission from Jane Smith"}

The current recommended format uses Block Kit:

{
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*New CF7 Submission*\n*Name:* Jane Smith\n*Email:* jane@example.com"
      }
    }
  ]
}

Old plugins that send the legacy text format still work for now but may produce warnings or stop working if Slack deprecates the simple text format fully. More importantly, if a plugin is sending a malformed payload, Slack returns an error that the plugin silently discards.

How to Connect CF7 to Slack Without a Dedicated Plugin

The most reliable approach is to call Slack's webhook directly from CF7 using Contact Form to API. You configure the Slack webhook URL as the API endpoint, set Content-Type: application/json as the header, and define the message payload using your CF7 field values.

A simple payload that puts the form data in a readable Slack message:

{
  "text": "New contact form submission:\n*Name:* [your-name]\n*Email:* [your-email]\n*Message:* [your-message]"
}

Or with Block Kit for a cleaner Slack message:

{
  "blocks": [
    {
      "type": "header",
      "text": {
        "type": "plain_text",
        "text": "New Website Enquiry"
      }
    },
    {
      "type": "section",
      "fields": [
        {"type": "mrkdwn", "text": "*Name:*\n[your-name]"},
        {"type": "mrkdwn", "text": "*Email:*\n[your-email]"}
      ]
    },
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*Message:*\n[your-message]"
      }
    }
  ]
}

Replace [your-name], [your-email], and [your-message] with your actual CF7 field names. Contact Form to API substitutes the real submitted values before sending the request to Slack.

No dedicated Slack plugin needed. No abandoned codebase to worry about. When Slack updates their webhook format, you update the payload in your settings.

Reason 4: Slack Rate Limiting or App Permissions

If notifications were working and then stopped intermittently, Slack may be rate limiting your webhook. Slack allows 1 message per second per webhook URL. If your form receives bursts of submissions, some Slack messages may be dropped with a 429 Too Many Requests response that the plugin never surfaces.

Also check whether the Slack app that owns your webhook is still installed in your workspace. Workspace admins can remove apps, which immediately invalidates all webhooks created by that app.

In Slack: go to your workspace settings, then Apps, and confirm your WordPress integration app is still listed and active.

Quick Diagnosis

# Step 1: Test your webhook URL directly
curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"CF7 webhook test"}' \
  https://hooks.slack.com/services/YOUR/WEBHOOK/URL

# Expected: ok
# invalid_token or no_service = webhook retired, create a new one
# channel_not_found = the channel was deleted or renamed

# Step 2: Check the channel still exists in Slack
# The channel the webhook was configured for must still exist

# Step 3: Confirm the plugin's last update date
# WordPress admin → Plugins → check "Last Updated" for your Slack plugin

CF7 to Notion Broke on August 11, 2026 - Here Is Exactly What Happened

Rahul Sharma — Mon, 07 Sep 2026 09:48:53 +0000

On August 11, 2026, Notion started strictly enforcing the Bearer prefix in Authorization headers. CF7-to-Notion plugin integrations that were working that morning were broken by that afternoon. Forms started showing errors to visitors. The Notion database list disappeared from the plugin settings. Every API call returned:

401 unauthorized: API token is invalid

The token was not invalid. The integration was not misconfigured. Notion simply changed how strictly it validates the Authorization header format - and the plugin was sending the token without the required Bearer prefix.

This is one of the cleanest and most thoroughly documented bugs I have seen in the WordPress support forums. The developer who filed the report identified the exact line of code, proved the cause with a command-line test, wrote a working workaround, and even flagged a PHP 9 breaking change in the same plugin. The plugin team responded within days with a patch.

The Root Cause: Missing `Bearer` Prefix in the Authorization Header

HTTP Bearer authentication requires this exact header format:

Authorization: Bearer secret_abc123...

The CF7 Notion addon (version 1.6.2 and earlier) was sending:

Authorization: secret_abc123...

The raw token, no prefix. This is the relevant line from the plugin source at includes/classes/class-api-notion.php:

'Authorization' => $this->secret_token,

Until August 11, Notion's API accepted both formats. After that date, Notion tightened its header parsing and started rejecting the bare token with a 401. The plugin code had not changed. Notion's validation had.

The developer confirmed this with a direct command-line test:

# With correct Bearer prefix — returns 200 OK
curl -H "Authorization: Bearer secret_..." https://api.notion.com/v1/databases

# Without Bearer prefix — returns 401
curl -H "Authorization: secret_..." https://api.notion.com/v1/databases

Same token. Same endpoint. Different header format. Different result.

If You Are on Plugin Version 1.6.2 or Earlier

Update to version 1.6.3 immediately. The plugin team released the fix on August 24, 2026. No settings changes are needed after updating. The plugin adds the Bearer prefix and also includes a guard for tokens that had the prefix manually added via the workaround filter.

If your automatic updates are delayed or you cannot update right now, apply this temporary fix using the WPCode or Code Snippets plugin:

add_filter( 'add-on-cf7-for-notion/notion-api/request-args', function( $args ) {
    if (
        ! empty( $args['headers']['Authorization'] ) &&
        0 !== stripos( $args['headers']['Authorization'], 'Bearer ' )
    ) {
        $args['headers']['Authorization'] = 'Bearer ' . $args['headers']['Authorization'];
    }
    return $args;
} );

Add this as a PHP snippet, activate it, then go to Contact in your WordPress admin and reload the Integration tab. Your Notion databases should reappear immediately.

Once you update to 1.6.3 you can safely remove this filter - the version 1.6.3 patch handles the Bearer prefix natively.

The PHP 9 Breaking Change Also In This Plugin

The same developer identified a second bug in the same code. The get_databases() pagination function contains:

sleep( 0.25 );

sleep() takes an integer argument. Passing 0.25 (a float) silently becomes 0 in PHP 8 - the intended quarter-second throttle never happens. On PHP 8.1+, this logs a deprecation notice:

PHP Deprecated: Implicit conversion from float 0.25 to int loses precision

On PHP 9, this becomes a TypeError - a fatal error that will break database listing entirely. The correct call is:

usleep( 250000 ); // 250,000 microseconds = 0.25 seconds

The plugin team included this fix in version 1.6.3 as well. If you are running PHP 8.1+ you may already see the deprecation notice in your error logs. Updating to 1.6.3 fixes it.

The Broader Lesson: External API Enforcement Changes Break Integrations Silently

This incident is a precise example of a category of failure that is extremely common but almost never anticipated: an external service changes how strictly it validates its API without breaking changes to the response format, and plugins that were previously working break overnight.

Notion did not change its API version. They did not remove an endpoint. They did not change the response format. They just started enforcing an existing requirement more strictly. The plugin's requests had always been technically malformed — they just happened to work until Notion decided to start caring.

This happens with auth headers, content-type headers, API version headers, and rate limiting. The plugin that worked for two years can fail on a Tuesday morning because the receiving service tightened validation on Monday evening.

The only way to know when this happens is to have response logging on every API call. Contact Form to API logs the response from every submission attempt. When Notion started returning 401s, you would have seen it in the log on the first failed submission rather than finding out when a client called to say their form was broken.

Connecting CF7 to Notion Directly

For a more resilient CF7 to Notion integration, you can call Notion's API directly rather than relying on a dedicated plugin.

Notion's API for creating a page (database row):

POST https://api.notion.com/v1/pages
Authorization: Bearer YOUR_NOTION_TOKEN
Content-Type: application/json
Notion-Version: 2022-06-28

{
  "parent": { "database_id": "YOUR_DATABASE_ID" },
  "properties": {
    "Name": {
      "title": [{ "text": { "content": "Jane Smith" } }]
    },
    "Email": {
      "email": "jane@example.com"
    },
    "Phone": {
      "phone_number": "1234567890"
    }
  }
}

Note that Notion requires the Notion-Version header (2022-06-28 is the current stable version). Property names in the payload must exactly match the column names in your Notion database. Property types (title, email, phone_number, rich_text, etc.) must match the column type configured in Notion.

Quick Reference

Symptom	Cause	Fix
401 on all Notion API calls from August 11, 2026	Plugin sending token without `Bearer` prefix	Update to v1.6.3 or apply filter workaround
Deprecation notices for `sleep(0.25)` in PHP logs	`sleep()` called with float argument	Update to v1.6.3 (uses `usleep(250000)` instead)
Will break on PHP 9	`sleep(0.25)` becomes `TypeError`	Update to v1.6.3 now
Notion databases not appearing in plugin after token entry	Same 401 issue	Same fix as above

CF7 REST API Returns `wpcf7_forbidden` 403 - Why It Happens and How to Fix It

Rahul Sharma — Thu, 03 Sep 2026 07:05:58 +0000

If you are building a headless WordPress site with React or Next.js and calling CF7's REST API, you have probably hit this:

{
  "code": "wpcf7_forbidden",
  "message": "You are not allowed to access the requested contact form.",
  "data": { "status": 403 }
}

The confusing part: you are logged in as an admin. You can see the form in the WordPress backend. But the API tells you that you are forbidden.

This happens because wpcf7_forbidden covers two completely different situations that need completely different fixes. Getting them mixed up is why most debugging attempts fail.

The Two Endpoints Are Not the Same

CF7 has two separate REST API endpoints and they have different authentication requirements:

GET endpoint — reads form configuration:

GET /wp-json/contact-form-7/v1/contact-forms/{id}

This returns the form's HTML, fields, and schema. It requires the user to have the wpcf7_edit_contact_form capability, which means they must be logged in as an administrator or editor. Unauthenticated requests always get wpcf7_forbidden.

POST endpoint — submits the form:

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

This processes a form submission. It does not require authentication. Any visitor can submit a form. But it does require specific hidden fields in the payload.

Most wpcf7_forbidden errors on the feedback endpoint are not authentication problems. They are missing field problems.

Cause 1: Calling the GET Endpoint Without Authentication

A developer posted on the WordPress forums that their headless React app was getting wpcf7_forbidden when fetching form data. They were calling:

GET /wp-json/contact-form-7/v1/contact-forms/21798

The CF7 source code for this endpoint's permission callback is:

'permission_callback' => static function (WP_REST_Request $request) {
    $id = (int) $request->get_param('id');
    if (current_user_can('wpcf7_edit_contact_form', $id)) {
        return true;
    } else {
        return new WP_Error(
            'wpcf7_forbidden',
            __('You are not allowed to access the requested contact form.', 'contact-form-7'),
            array('status' => 403)
        );
    }
},

This capability check (wpcf7_edit_contact_form) returns false for unauthenticated requests. There is no way around this without authentication.

The fix: Do not call the GET endpoint from client-side code without authentication. Instead, fetch the form HTML server-side in Next.js using your WordPress credentials, then render it client-side. Or hardcode the form HTML from WordPress admin and skip the GET endpoint entirely.

In Next.js, fetch the form server-side:

// In a Next.js Server Component or getServerSideProps
const response = await fetch(
  `${process.env.WP_URL}/wp-json/contact-form-7/v1/contact-forms/${formId}`,
  {
    headers: {
      Authorization: 'Basic ' + Buffer.from(
        `${process.env.WP_USER}:${process.env.WP_APP_PASSWORD}`
      ).toString('base64'),
    },
  }
);
const formData = await response.json();

Use WordPress Application Passwords (generated under Users, Profile, Application Passwords) rather than your account password.

Cause 2: Missing Required Hidden Fields on the Feedback Endpoint

When the wpcf7_forbidden error appears on the POST feedback endpoint during form submission (not the GET endpoint), the cause is almost always missing hidden fields in the payload.

CF7's feedback endpoint requires these fields alongside your form data:

Field	Value	Where to get it
`_wpcf7`	Form ID (integer)	From the form's edit URL in WordPress admin
`_wpcf7_version`	CF7 version	From the rendered form HTML
`_wpcf7_locale`	Site locale	Usually `en_US`
`_wpcf7_unit_tag`	Unique form tag	From the rendered form HTML
`_wpcf7_container_post`	Post ID where form is embedded	`0` if not embedded in a post

A minimal correct payload:

const formData = new FormData();
formData.append('_wpcf7', '123');               // your form ID
formData.append('_wpcf7_version', '5.9.8');     // CF7 version
formData.append('_wpcf7_locale', 'en_US');
formData.append('_wpcf7_unit_tag', 'wpcf7-f123-p456-o1');
formData.append('_wpcf7_container_post', '0');
formData.append('your-name', 'Jane Smith');
formData.append('your-email', 'jane@example.com');
formData.append('your-message', 'Hello');

const response = await fetch(
  `https://your-wp-site.com/wp-json/contact-form-7/v1/contact-forms/123/feedback`,
  {
    method: 'POST',
    body: formData,
  }
);

The _wpcf7_unit_tag value is generated by CF7 when it renders the form. In a headless setup, you can either fetch it from the GET endpoint server-side or construct it using the pattern wpcf7-f{formId}-p{postId}-o{instance}.

Cause 3: Nginx Redirect Misconfiguration

One developer reported wpcf7_forbidden appearing on all their forms suddenly with no other changes. After debugging, they found it was caused by a redirect rule in their Nginx configuration that was rewriting the request URL before it reached WordPress.

The Nginx rule was modifying the path in a way that stripped or altered the form ID segment of the URL. WordPress received a modified URL that did not match the route pattern, fired the permission callback with incorrect parameters, and returned wpcf7_forbidden.

If your wpcf7_forbidden error appeared suddenly without any code changes, check your Nginx configuration for any recently added location blocks or rewrite rules that might affect /wp-json/ paths.

The Headless CF7 Integration Pattern That Avoids All of This

If you are building a headless WordPress site and your goal is to collect form data and send it somewhere useful (a CRM, an email service, a Slack channel), there is a simpler architecture that avoids the REST API authentication complexity entirely.

Keep CF7 on the WordPress side. Use Contact Form to API to forward form submissions to your external service via the server-side wpcf7_before_send_mail hook. Your Next.js or React frontend embeds the WordPress CF7 form directly (via an iframe or a fetched HTML block), the form submits to WordPress normally, and WordPress forwards the data to your CRM.

No GET endpoint authentication. No hidden field management. No CORS configuration. The form submission stays within the WordPress ecosystem and the outbound CRM call happens server-to-server.

Quick Reference

Scenario	Error cause	Fix
Calling GET endpoint without auth	`wpcf7_edit_contact_form` capability check fails	Use Application Password auth server-side
POST feedback with missing fields	Required hidden fields absent	Include all `_wpcf7_*` hidden fields
Sudden 403 on all forms, no code change	Nginx redirect modifying URL	Check Nginx config for recently added rewrite rules
Intermittent 403 on form submission	Nonce expired between page load and submit	CF7 handles nonces internally — usually not the cause on standard submissions

CF7 REST API Returns `rest_no_route` 404 Every Cause Explained

Rahul Sharma — Wed, 02 Sep 2026 10:28:12 +0000

The error looks the same every time:

{
  "code": "rest_no_route",
  "message": "No route was found matching the URL and request method.",
  "data": { "status": 404 }
}

But the causes are completely different depending on your setup. Across multiple WordPress support threads, developers have hit this error from four separate root causes that look identical in the browser console. This post covers all four so you can identify and fix yours in one pass.

What `rest_no_route` Actually Means

rest_no_route is WordPress telling you it received an HTTP request to a URL that does not match any registered REST API route. It is a routing failure, not an authentication failure, not a plugin failure, and not a CF7 failure.

WordPress's REST API router receives the request and looks through its registered routes for a match. When nothing matches, it returns this 404. The cause is always something that prevents the URL from reaching the correct route handler.

Cause 1: Wrong Form ID in the URL

This was the resolution in the most-viewed thread on the topic. A developer was testing the feedback endpoint in Postman using this URL:

/wp-json/contact-form-7/v1/contact-forms/fc7114d/feedback

The CF7 plugin author's reply was direct: fc7114d is not a contact form ID. CF7 form IDs are integers, not alphanumeric strings.

The correct URL format is:

POST /wp-json/contact-form-7/v1/contact-forms/123/feedback

Where 123 is the integer ID of your specific CF7 form. Find it in the WordPress admin under Contact, Contact Forms. The form ID appears in the URL when you open the form for editing: post=123.

If you are following a tutorial or building a headless Next.js integration, make sure the form ID you are using is the actual integer ID of a real form on your site, not a placeholder or slug.

Cause 2: WP Rocket Caching the REST API Response

This was the cause in two separate threads. A developer reported that CF7 forms stopped submitting suddenly with the rest_no_route error. When they disabled WP Rocket, the forms worked immediately. Re-enabling WP Rocket brought the error back.

WP Rocket can cache REST API responses under certain configurations. When a cached 404 response for the feedback URL is served instead of the live WordPress router handling the request, rest_no_route appears even though the route exists and is correctly registered.

Fix: In WP Rocket settings, go to Advanced Rules and add the CF7 feedback URL pattern to the "Never Cache URLs" list:

/wp-json/contact-form-7/(.*)

Also check WP Rocket's CDN settings if you use one. Some CDN configurations cache API responses at the edge level, which requires an edge rule to bypass caching for /wp-json/ paths.

Cause 3: `.htaccess` or Nginx Misconfiguration

A plugin author response in one thread identified this directly: the rest_no_route error can be caused by Apache mod_rewrite rules or an Nginx server block that is not correctly passing requests to WordPress's REST API handler.

For Nginx servers, the REST API requires this location block:

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~ /wp-json/ {
    rewrite ^/wp-json/(.*)$ /index.php?rest_route=/$1 last;
}

Without the second block, Nginx does not know how to route /wp-json/ requests to WordPress's PHP handler. Requests fall through to a 404 at the server level before WordPress even sees them.

For Apache, re-saving your WordPress permalinks usually regenerates the .htaccess file with the correct rewrite rules. Go to Settings, then Permalinks, and click Save Changes without changing anything.

One developer in the forums reported that re-saving permalinks temporarily fixed the issue but it kept returning. This is a sign of a plugin or a deployment process overwriting the .htaccess file. Check whether any deployment script or security plugin regenerates .htaccess without the correct WordPress rewrite rules.

Cause 4: HTTP to HTTPS Redirect Intercepting the API Request

One thread showed a CORS error alongside the rest_no_route response. The actual issue was that the site had references to the HTTP version of the domain (http://) somewhere in its configuration. When CF7's JavaScript fired the feedback request over HTTPS, a redirect from HTTP to HTTPS was intercepting it and the redirect destination was serving a 404.

Check your browser's Network tab when submitting a form. If you see a redirect (301 or 302) happening before the 404, the request is being redirected somewhere it should not be. Confirm that all references to your domain in WordPress settings use HTTPS, not HTTP:

WordPress Address (URL): https://yourdomain.com
Site Address (URL): https://yourdomain.com

If these are set to HTTP, update them under Settings, General, and then clear any caches.

Confirming the Route Is Actually Registered

Before debugging any of the above, confirm that CF7's REST API route exists on your site by visiting:

https://yourdomain.com/wp-json/contact-form-7/v1/contact-forms

If you see a JSON array of your forms, the route is registered correctly and the problem is in the feedback submission specifically. If you see rest_no_route even at this URL, CF7 itself may not be active or there is a server-level routing problem blocking all /wp-json/ requests.

A Different Architecture: Skip the REST API Dependency

The rest_no_route error exists because CF7's form submission uses the REST API by default. Every caching layer, server configuration, and security plugin that touches /wp-json/ is a potential point of failure.

If your goal is to send CF7 form data to an external CRM or API, Contact Form to API handles the outbound API call from the server side on wpcf7_before_send_mail. The form submission goes through CF7's normal processing path, not through the REST API endpoint. There is no /wp-json/feedback URL for caching plugins to intercept or for server routing misconfigurations to break.

Quick Diagnosis Checklist

Symptom	Most Likely Cause
Error in Postman with alphanumeric form ID	Wrong form ID format — use integer ID
Works with WP Rocket disabled	WP Rocket caching `/wp-json/` — add never-cache rule
Intermittent error, re-saving permalinks fixes temporarily	`.htaccess` being overwritten
Redirect visible in Network tab before the 404	HTTP/HTTPS mismatch in site URL settings
`rest_no_route` even at `/wp-json/contact-form-7/v1/contact-forms`	CF7 not active or server blocking all REST routes

CF7 to GetResponse Not Adding Contacts - What Is Actually Wrong

Rahul Sharma — Tue, 01 Sep 2026 10:35:00 +0000

A reviewer left this on the WordPress plugin page for the CF7 GetResponse Extension:

"The UI is great on the backend but the plugin is not working and there are no logs for me to see why contacts are not being added. Please fix."

Another review from earlier said:

"Not working. Display error 'Invalid key' even key is valid."

Both describe the same underlying situation: the integration appears set up correctly, the form submits without error, and GetResponse receives nothing. No error message. No log entry. Just silence.

There are three reasons this happens with CF7 to GetResponse integrations, and none of them have anything to do with your API key being wrong.

Reason 1: GetResponse Deprecated Their API - The Plugin Still Uses the Old Endpoint

GetResponse updated their API from v2 to v3 several years ago and the v2 endpoints have been progressively deprecated. The CF7 GetResponse Extension plugin was built against the older API. If your API key is valid but the plugin keeps saying it is invalid, the request is reaching a deprecated or retired endpoint rather than GetResponse's current API.

GetResponse's current API base URL is:

https://api.getresponse.com/v3/

Older integrations may be hitting:

https://api.getresponse.com/v2/

Requests to v2 endpoints either return an error or are silently rejected depending on when GetResponse retired them. The "invalid key" error in this scenario is not about the key itself. It is about sending a valid key to an endpoint that no longer accepts it.

Reason 2: No Error Logging in the Plugin

The reviewer's complaint about no logs is a real architectural problem. When the plugin fires an API call to GetResponse and receives an error response, it has nowhere to surface that error to you. The form shows success. GetResponse gets nothing. The plugin does not write to the WordPress error log. You have no signal that anything went wrong.

To manually diagnose what GetResponse is actually receiving, enable WordPress debug logging temporarily:

// Add to wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

Then test the GetResponse API directly with your key to confirm it works independently of WordPress:

curl -X GET "https://api.getresponse.com/v3/campaigns" \
  -H "X-Auth-Token: api-key YOUR_GETRESPONSE_API_KEY"

Note the header format: GetResponse API v3 uses X-Auth-Token: api-key YOUR_KEY, not Authorization: Bearer YOUR_KEY. If you see a list of campaigns in the response, your key is valid. If you see an authentication error, regenerate the key in GetResponse under Tools, API, API key.

Reason 3: Field Shortcode Placement Bug

One reviewer discovered that the plugin fails to detect form fields correctly when two CF7 shortcodes appear on the same line in the form template:

[text* your-name placeholder "Name"] [email* your-email placeholder "Email"]

The plugin scans the form template to build the field mapping dropdown. When shortcodes share a line, the regex parsing misses the email field and it never appears in the mapper. You map your CF7 form to GetResponse but the email field is empty, so GetResponse rejects the contact creation silently because email is a required field.

The fix is simple: put each CF7 shortcode on its own line in the form editor:

[text* your-name placeholder "Name"]
[email* your-email placeholder "Email"]
[submit "Send"]

After saving the form with this layout, go back to the plugin settings and re-map the fields. The email field should now appear in the dropdown.

The GetResponse API V3 Direct Integration

If the dedicated plugin continues to fail after these fixes, calling GetResponse's API directly removes the dependency on the plugin's implementation staying current.

GetResponse V3 API for adding a contact to a campaign:

POST https://api.getresponse.com/v3/contacts
X-Auth-Token: api-key YOUR_API_KEY
Content-Type: application/json

{
  "email": "jane@example.com",
  "name": "Jane Smith",
  "campaign": {
    "campaignId": "YOUR_CAMPAIGN_ID"
  }
}

Get your campaign ID:

curl -X GET "https://api.getresponse.com/v3/campaigns" \
  -H "X-Auth-Token: api-key YOUR_API_KEY"

The campaignId field appears in the response for each campaign.

Contact Form to API lets you configure this API call from the WordPress dashboard without PHP. You set the GetResponse endpoint, add the X-Auth-Token header with your key, and map your CF7 fields to the JSON body. Every submission calls GetResponse's v3 API directly. You see the response in the logs so you know immediately whether the contact was added.

Quick Checklist

If your CF7 to GetResponse integration is not adding contacts, go through these in order.

Test your API key directly against the v3 campaigns endpoint to confirm it is valid.

Check whether each CF7 shortcode is on its own line in the form template. If not, fix the line breaks and remap the fields.

Enable WP_DEBUG_LOG and check for any error after a test submission.

If the dedicated plugin is using an outdated API endpoint and you cannot update it, switch to a direct API call using Contact Form to API with GetResponse's v3 endpoint.

CF7 + Zoho CRM: New Leads Overwriting Existing Records Instead of Creating New Ones

Rahul Sharma — Mon, 31 Aug 2026 12:03:22 +0000

A site owner posted on the WordPress forums with a specific and frustrating problem. When someone submitted their CF7 form with the same name or similar data as an existing lead in Zoho CRM, the plugin was updating that existing record instead of creating a new one. Duplicate names were colliding. Real new leads were being lost by being merged into old records.

The plugin support team's reply was two sentences. The free version does not support this. Buy the Pro version.

Thread closed as resolved. The problem was not resolved for anyone who did not want to pay for a Pro upgrade just to control whether new leads get created or merged.

This post explains why this happens, what the Zoho API actually does with duplicate records, and how to handle it correctly without being forced into a Pro upgrade.

Why the Plugin Overwrites Records Instead of Creating New Ones

Zoho CRM's API has two different endpoints for creating Lead records:

Create (always new):

POST https://www.zohoapis.com/crm/v2/Leads

This always creates a brand new record regardless of whether a record with the same name or email already exists.

Upsert (create or update):

POST https://www.zohoapis.com/crm/v2/Leads/upsert

This checks for a matching record first. If it finds one, it updates it. If it does not find one, it creates a new record.

Most dedicated CF7 to Zoho plugins use the upsert endpoint by default because it avoids true duplicate records for the same person. But "same person" in Zoho's matching logic is determined by the duplicate check fields you configure in your Zoho account - typically email address.

The problem in the forum thread was that the plugin was matching on name rather than email, or the Zoho account had duplicate check fields set to something other than email. When two leads had the same name or similar data, Zoho treated them as the same person and updated the existing record instead of creating a new one.

How Zoho's Duplicate Check Actually Works

In your Zoho CRM account, under Setup, then CRM Settings, then Modules and Fields, you can configure which fields are used to identify duplicate records. For Leads, the default is typically Email.

If duplicate check is set to Email and two different people submit your form with different email addresses, Zoho will create two separate Lead records even if their names are identical. The email address is the unique identifier.

If duplicate check is configured to include Last Name or Company, two leads with the same last name or company will collide and the second submission will update the first record.

The forum user's problem was almost certainly in this Zoho-side configuration, not in the plugin itself. Checking and correcting the duplicate check fields in Zoho settings would have resolved it without needing the Pro version.

To check this in Zoho: go to Setup, then Zoho CRM Settings, then Duplicate Check Preferences under the Leads module. Confirm that Email is the primary deduplication field and that Name is not included.

When You Genuinely Need Always-Create Behaviour

Some businesses do need to always create a new Lead regardless of whether a matching record exists. For example, a business that tracks every enquiry separately even from returning contacts, or one where the same person might legitimately submit multiple distinct enquiries.

For this use case, the correct API call is the basic create endpoint, not upsert. The free plugin defaulting to upsert is not wrong - it prevents genuine duplicates. But the option to override this and always create a new record should not require a paid upgrade.

Controlling This With a Direct API Integration

Contact Form to API lets you configure exactly which Zoho endpoint receives your form data. You choose the create endpoint if you always want new records, or the upsert endpoint if you want deduplication. That choice lives in your settings, not behind a paywall.

For always-create behaviour, configure the endpoint as:

POST https://www.zohoapis.com/crm/v2/Leads

With a payload like:

{
  "data": [
    {
      "Last_Name": "[your-name]",
      "Email": "[your-email]",
      "Phone": "[your-phone]",
      "Lead_Source": "Web Form"
    }
  ]
}

For upsert behaviour with email as the matching field, use:

POST https://www.zohoapis.com/crm/v2/Leads/upsert

With the same payload. Zoho will match on the duplicate check fields configured in your account settings.

You also get a response log for every submission so you can see whether Zoho created a new record or updated an existing one, and the exact record ID returned.

Fixing the Duplicate Check in Zoho First

Before changing any plugin settings, go into your Zoho CRM account and confirm your duplicate check configuration. This is the most likely cause of the forum user's problem and it costs nothing to fix.

In Zoho CRM: Setup, then CRM Settings, then Modules, then Leads, then Duplicate Check Preferences. Ensure Email is selected as the duplicate check field and that Last Name is not included unless you specifically want last name matching.

If you want Zoho to always create new records regardless of any matching field, you can also disable the duplicate check entirely for the Leads module. New leads will always be created and no merging will happen.

Summary

Leads being overwritten instead of creating new records in Zoho CRM is almost always a duplicate check configuration issue, not a plugin bug. The fix is in Zoho's settings, not in buying a Pro plugin upgrade.

For businesses that need explicit control over create vs upsert behaviour without depending on which tier of a dedicated plugin they are on, a direct API integration gives you that control from a configuration setting rather than a pricing tier.

Your Contact Form Created the Deal... Just in the Wrong Pipeline

Rahul Sharma — Fri, 07 Aug 2026 11:16:37 +0000

One of the most interesting CRM bugs I've seen recently wasn't caused by a failed API request.

In fact, the API worked perfectly.

The website visitor filled out a Contact Form 7 form, the request reached Pipedrive successfully, and a new deal was created.

Everything looked good...

Until the sales team opened Pipedrive.

The deal had been created in the wrong pipeline.

That meant automations didn't trigger, sales representatives never saw the enquiry in their normal workflow, and reporting immediately became inaccurate.

Technically, nothing failed.

From a business perspective, everything did.

A discussion in the Pipedrive Community highlighted this exact type of issue. Developers expected website enquiries to enter a specific pipeline, but instead they were landing in the default one. It's a subtle problem, yet it's surprisingly common when building CRM integrations.

HTTP 200 doesn't mean "problem solved"

Developers often celebrate this response:

```http id="dev01"
HTTP/1.1 200 OK




And rightly so.

It confirms the API accepted the request.

But here's the catch:

A successful API response only tells you **the request was processed**.

It doesn't tell you whether the CRM created the record exactly the way your business expected.

There's a big difference between:



```text id="flow01"
✓ Deal Created

and

```text id="flow02"
✓ Deal Created
✗ Wrong Pipeline
✗ Wrong Stage
✗ Wrong Workflow




The API succeeded.

The implementation didn't.

## Your CRM workflow starts long before someone calls the customer

Sales pipelines exist for a reason.

They're more than visual boards.

Each pipeline usually has its own:

* automation rules
* notification workflows
* ownership logic
* reporting
* probability calculations
* sales stages

If a website enquiry lands in the wrong pipeline, all of those downstream processes are affected.

That's why pipeline mapping deserves as much attention as authentication or field validation.

## Contact Form 7 only collects information

One misconception I still hear is:

> "Contact Form 7 created the deal in the wrong pipeline."

Not exactly.

Contact Form 7 doesn't know anything about pipelines.

Its responsibility ends after collecting user input.

The workflow actually looks like this:



```text id="flow03"
Visitor
      │
      ▼
Contact Form 7
      │
      ▼
API Integration
      │
      ▼
Pipedrive
      │
      ▼
Pipeline Assignment

The pipeline isn't chosen by the form.

It's determined by the API request.

The payload decides the destination

Imagine two requests.

The first one contains almost no business information.

```json id="json01"
{
"title": "Website Enquiry"
}




The CRM creates a deal.

But because no pipeline information is supplied, it uses its default configuration.

Now compare that with a more complete request.



```json id="json02"
{
  "title": "Website Demo Request",
  "pipeline_id": 4,
  "stage_id": 2
}

Exactly the same API.

Completely different outcome.

That's why understanding the CRM's payload structure is just as important as understanding the API endpoint itself.

Mapping should follow the business process

Whenever I build CRM integrations, I start with a simple question:

Where should this enquiry appear the moment it's created?

The answer changes everything.

A contact form might create a deal in the Sales pipeline.

A demo request could enter the Product Demo pipeline.

A partnership enquiry may belong in a Business Development pipeline.

Trying to send every form into the same workflow usually creates more manual work later.

What I check before deploying

Before I consider any CRM integration complete, I verify:

Is the correct endpoint being used?
Is the pipeline ID correct?
Is the stage ID correct?
Are custom fields mapped properly?
Does the created record appear where the sales team expects?

Only then do I know the integration is actually finished.

Where Contact Form to API helps

This is where Contact Form to API becomes useful.

Instead of treating every Contact Form 7 submission the same way, it allows developers to build API requests that match the CRM's requirements.

That includes configuring custom payloads, mapping fields, and sending requests to external APIs without being locked into a fixed workflow.

If you're integrating Contact Form 7 with Pipedrive, these resources are worth checking out:

Easily Connect Contact Form 7 with Pipedrive
https://www.contactformtoapi.com/easily-connect-contact-form-7-with-pipedrive/
Contact Form 7 JSON Mapping
https://www.contactformtoapi.com/contact-form-7-json-mapping/
Contact Form 7 CRM Integration Guide
https://www.contactformtoapi.com/contact-form-7-crm-integration/

Final thoughts

One thing I've learned from building integrations is this:

Moving data isn't the hard part.

Moving it into the right workflow is.

A deal sitting in the wrong pipeline can be just as damaging as a deal that never arrived at all.

The next time you're testing a Contact Form 7 integration, don't stop after seeing HTTP 200 OK.

Open your CRM.

Check the pipeline.

Check the stage.

Check whether the automation actually reflects how the business operates.

That's the difference between an integration that works and one that's genuinely useful.

Have you ever deployed a CRM integration that technically worked but still created operational problems because records landed in the wrong place? How did you solve the mapping?

Contact Form 7 and Pipedrive Not Talking? Debug the Integration, Not the Form

Rahul Sharma — Thu, 06 Aug 2026 11:27:28 +0000

A client once reported a simple issue:

"People are submitting the contact form, but nothing is showing up in Pipedrive."

If you've worked with WordPress long enough, you've probably heard a variation of that sentence.

The immediate assumption is usually:

Contact Form 7 is broken.
WordPress isn't sending emails.
The CRM plugin has a bug.

But after investigating enough production issues, I've learned something different.

Most integration failures aren't caused by Contact Form 7. They're caused by the layer that connects Contact Form 7 to the CRM.

A discussion in the Pipedrive Developer Community reflected this exact frustration getting Contact Form 7 to work with Pipedrive wasn't as straightforward as expected. While the technologies may differ from project to project, the debugging process is almost always the same.

The form isn't the entire workflow

It's easy to think about the process like this:

Visitor
    │
    ▼
Contact Form 7
    │
    ▼
Pipedrive

In reality, several components sit between the form and the CRM.

Visitor
    │
    ▼
Contact Form 7
    │
    ▼
HTTP Request
    │
    ▼
Authentication
    │
    ▼
Pipedrive API
    │
    ▼
CRM Record

If any step in the middle fails, the form can still appear to work while the CRM receives nothing.

That's why debugging the entire request lifecycle is more important than changing form settings.

My first rule: Never assume the API received the data

One mistake I see frequently is treating a successful form submission as proof that the CRM has the data.

Those are two separate events.

Before touching any configuration, I ask a few simple questions:

Did Contact Form 7 process the submission?
Was an HTTP request actually sent?
Did the API return a response?
Was authentication successful?
Did the CRM accept the payload?
Was the expected record created?

Answering these questions usually narrows the problem down very quickly.

Common reasons integrations fail

After debugging several API integrations, I've noticed the same issues appear repeatedly.

Authentication problems

An expired API token or incorrect credentials can cause every request to fail.

Incorrect endpoint

Sending data to the wrong API endpoint means the CRM either rejects the request or creates an unexpected result.

Payload mismatch

The CRM may expect fields that the form isn't sending, or it may reject values that don't match its schema.

Network or timeout issues

Sometimes the request never reaches the CRM because of connectivity problems or server timeouts.

Missing request visibility

This is probably the biggest challenge.

Without logs, you're left asking:

"Did the request ever leave WordPress?"

And that's not a good place to start.

The integration layer deserves more attention

Contact Form 7 does exactly what it's designed to do it collects user input.

Everything after that depends on the integration.

That's why I think developers should spend less time replacing form plugins and more time improving:

request logging
payload validation
authentication handling
API response monitoring
retry strategies

These improvements make integrations easier to support and far more reliable in production.

Building a more resilient workflow

When integrating Contact Form 7 with a CRM like Pipedrive, I aim for a workflow that looks like this:

Submit Form
      │
      ▼
Validate Data
      │
      ▼
Send API Request
      │
      ▼
Log Request & Response
      │
      ▼
Create CRM Record
      │
      ▼
Handle Failures Gracefully

That extra visibility pays for itself the first time something goes wrong.

Where Contact Form to API fits

If you're using Contact Form 7 and need more control over API integrations, Contact Form to API focuses on the integration layer rather than replacing your forms.

It allows developers to send submissions directly to external APIs while configuring endpoints, authentication, headers, and request payloads to match the target system.

If you're working with Pipedrive, these resources are worth exploring:

Easily Connect Contact Form 7 with Pipedrive
https://www.contactformtoapi.com/easily-connect-contact-form-7-with-pipedrive/
Contact Form 7 Data Not Reaching API
https://www.contactformtoapi.com/contact-form-7-data-not-reaching-api/
Contact Form 7 API Authentication Error
https://www.contactformtoapi.com/contact-form-7-api-authentication-error/

Final thoughts

When an integration fails, it's tempting to blame the form because that's the part users interact with.

In reality, the form is usually doing its job.

The real challenge is ensuring the API request reaches the CRM, is accepted, and creates the expected record.

The next time someone says, "Contact Form 7 isn't working," don't start by replacing the plugin.

Start by tracing the request.

You'll often discover that the problem isn't the form at all—it's the integration between the form and the CRM.

How do you debug Contact Form 7 integrations in production?

Do you rely on request logs, API monitoring, webhook testing, or another workflow? I'd be interested to hear how other developers approach these issues.

Your API Worked Perfectly… It Just Created the Wrong CRM Record

Rahul Sharma — Wed, 05 Aug 2026 11:08:57 +0000

One of the easiest mistakes to make when integrating a CRM isn't a failed API request.

It's a successful one.

Recently, I came across a discussion from a developer integrating Contact Form 7 with Pipedrive. Every submission from the website reached the CRM successfully, but instead of creating a Deal, it created a Contact (Person).

At first glance, everything looked correct.

The API returned a success response.

No errors were logged.

The data reached Pipedrive.

Yet the sales team couldn't use the records because every enquiry was ending up in the wrong place.

This is a good reminder that a successful HTTP request doesn't always mean you've achieved the business outcome you wanted.

The API did exactly what it was told

When developers see the wrong object being created, the first instinct is often to blame the form plugin.

But Contact Form 7 isn't responsible for deciding whether a CRM should create a Contact, Lead, Deal, or Opportunity.

Its job is much simpler.

```text id="2q9rka"
Collect Form Data
│
▼
Pass Data Forward




Everything after that depends on the integration.

The API only processes the request it receives.

If the request targets the Contacts endpoint, the CRM creates a Contact.

If it targets the Deals endpoint, it creates a Deal.

From the API's perspective, both requests are perfectly valid.

## CRMs organize data differently

Almost every modern CRM separates different business entities.

For example:



```text id="mr4c5u"
Person
Organization
Lead
Deal
Activity

Although they're related, each object serves a different purpose.

A Contact identifies a person.

A Deal represents a sales opportunity.

An Organization groups companies.

An Activity tracks work.

Choosing the wrong endpoint changes the entire workflow.

That's why developers should understand the CRM's data model before writing any integration code.

Success isn't just about HTTP 200

Imagine this request.

```http id="9k2vbm"
POST /persons

HTTP/1.1 200 OK




Technically, everything worked.

But what if the client expected:



```text id="0cfd0o"
Website Enquiry
        │
        ▼
New Deal

Instead, they got:

```text id="jny7ns"
Website Enquiry
│
▼
New Contact




The API isn't broken.

The integration logic is.

This is why I try to separate **technical success** from **business success** whenever I'm reviewing integrations.

## Before writing code, understand the workflow

When integrating Contact Form 7 with any CRM, I always ask one question first:

> **What should happen after someone submits this form?**

Different forms often have different answers.

A contact form might create a Contact.

A demo request might create a Deal.

A support request might create a Ticket.

A partnership enquiry might create an Organization.

Treating every form submission the same usually creates problems later.

Instead, start with the business workflow and then map the API around it.

## Payloads matter just as much as endpoints

Even when you've selected the correct endpoint, the payload still needs to match what the API expects.

For example:



```json id="j5h8tx"
{
  "title": "Website Demo Request",
  "person_id": 123,
  "pipeline_id": 2,
  "stage_id": 5
}

A Deal typically requires different fields than a Contact.

Without the required values, the CRM may reject the request or create incomplete records.

Whenever I'm debugging integrations, I check:

endpoint
HTTP method
required fields
JSON structure
authentication
object relationships

Those six things solve far more problems than changing the form itself.

Build integrations that match the CRM

One lesson I've learned over the years is that APIs shouldn't dictate your business process.

Your business process should dictate how you use the API.

If your sales team works with Deals, then your integration should create Deals.

If marketing works with Leads, then create Leads.

If support manages Tickets, then create Tickets.

The integration should reflect how people actually work inside the CRM.

Where Contact Form to API helps

This is one area where Contact Form to API gives developers much more flexibility than fixed CRM connectors.

Instead of forcing every Contact Form 7 submission into a predefined workflow, it allows you to send requests to custom API endpoints with payloads that match your CRM's requirements.

That means you're not limited to creating one type of object.

You decide which endpoint receives the request and how the data is structured.

If you're working with Pipedrive, these guides are a good starting point:

Easily Connect Contact Form 7 with Pipedrive
https://www.contactformtoapi.com/easily-connect-contact-form-7-with-pipedrive/
Contact Form 7 JSON Mapping
https://www.contactformtoapi.com/contact-form-7-json-mapping/
Contact Form 7 CRM Integration Guide
https://www.contactformtoapi.com/contact-form-7-crm-integration/

Final thoughts

One of the best lessons API integrations teach us is this:

A successful request isn't always a successful integration.

The server can return 200 OK.

The CRM can create a record.

Everything can look technically correct.

Yet the business workflow can still be completely wrong because the integration created the wrong object.

Before blaming Contact Form 7 or even the CRM take a step back and inspect the integration itself.

Ask:

Did I choose the correct endpoint?
Does this object match the client's workflow?
Is my payload aligned with the CRM's schema?

Those three questions will prevent far more problems than endlessly tweaking form settings.

Have you ever integrated a CRM only to discover it was creating the wrong records? Was the issue the endpoint, the payload, or something else entirely? I'd love to hear how you solved it.

The API Failed. The Customer Never Knew. Here's Why Logging Matters

Rahul Sharma — Mon, 03 Aug 2026 11:38:41 +0000

One of the most frustrating bugs I've debugged wasn't a PHP exception or a broken API endpoint.

It was a successful Contact Form 7 submission.

At least, that's what everyone thought.

The user filled out the form, clicked Submit, received the success message, and left the website.

A few days later, the client asked:

"Why isn't this lead in our CRM?"

That question immediately changes the investigation.

You're no longer debugging Contact Form 7.

You're debugging everything that happens after Contact Form 7.

The success message lies (sometimes)

When Contact Form 7 displays:

Your message has been sent successfully.

it only confirms one thing.

The form submission was accepted by WordPress.

It doesn't guarantee that:

the API request was sent
authentication succeeded
the CRM accepted the payload
the lead was created
downstream automations completed

Those are completely different steps.

A typical workflow actually looks like this:

```text id="d3v1ab"
Visitor
│
▼
Contact Form 7
│
▼
API Request
│
▼
CRM API
│
▼
Lead Created




If the request fails anywhere after the form submission, the visitor will probably never know.

Unfortunately, neither will the business.

## APIs fail for perfectly normal reasons

When developers first build integrations, it's easy to assume:



```text id="z5m8cn"
Submit
   ↓
Success

Production environments are rarely that simple.

An API request can fail because:

authentication tokens expired
endpoint URLs changed
required fields are missing
payload validation failed
the API is rate limited
the server timed out
temporary network issues occurred

None of those mean your integration is poorly written.

They're simply realities of working with external services.

The real question becomes:

Can your integration tell you exactly what happened?

Debugging without logs is mostly guessing

Imagine receiving this support ticket:

"Five enquiries never reached Insightly."

Without logs, your investigation usually sounds like this:

"Maybe the CRM was unavailable?"

"Maybe SMTP failed?"

"Maybe Contact Form 7 didn't submit?"

"Maybe WordPress cached something?"

Notice how every sentence starts with maybe.

Now imagine having request logs.

Instead, you immediately see:

```http id="c8n4fd"
POST /v3.1/Contacts
HTTP 401 Unauthorized




or



```http id="m2x7qe"
HTTP 408 Request Timeout

```http id="r4w1jy"
HTTP 422 Validation Error
company_name is required




The debugging process changes completely.

You're no longer guessing.

You're reading evidence.

## Every API integration should answer three questions

Whenever I integrate Contact Form 7 with an external system, I want the workflow to answer three things immediately.

### 1. Was the request sent?



```text id="k7f3we"
Contact Form 7
      │
      ▼
HTTP Request
      ✓

2. What response came back?

```http id="v1h9ra"
HTTP 200 OK




or



```http id="y8b2ld"
HTTP 401 Unauthorized

3. Can I resend it?

Because temporary failures shouldn't force customers to submit the form again.

If authentication expired or the CRM experienced downtime, I'd much rather fix the issue and replay the original request.

The customer shouldn't even know something went wrong.

Retry support is more valuable than people think

Imagine your CRM goes offline for fifteen minutes.

During that period:

```text id="t6m2bo"
Lead 1 ❌
Lead 2 ❌
Lead 3 ❌
Lead 4 ❌




Without retry functionality:

Those leads are gone.

With retry functionality:



```text id="a9q7uv"
Issue Fixed
      │
      ▼
Replay Requests
      │
      ▼
All Leads Delivered

That's a completely different outcome.

The customer experience remains unchanged.

The business keeps its enquiries.

Developers spend less time explaining what happened.

Improving the integration layer

One thing I've learned is that Contact Form 7 is rarely the problem.

It already does its job well.

The weak point is usually the integration layer between WordPress and the external API.

That's the part that deserves attention.

Instead of replacing the form plugin, I prefer improving:

request visibility
payload validation
authentication
error logging
retry handling

Those improvements produce much more reliable systems.

Where Contact Form to API fits

If you're already using Contact Form 7, Contact Form to API focuses on exactly that integration layer.

Rather than replacing your forms, it helps send submissions directly to external APIs while giving developers better visibility into requests and failures.

If you've ever encountered situations where submissions weren't reaching an external system, these guides are worth bookmarking:

Contact Form 7 Data Not Reaching API
https://www.contactformtoapi.com/contact-form-7-data-not-reaching-api/
Contact Form 7 API Authentication Error
https://www.contactformtoapi.com/contact-form-7-api-authentication-error/
Contact Form 7 API Timeout
https://www.contactformtoapi.com/contact-form-7-api-timeout/

Final thoughts

One successful API request doesn't prove an integration is reliable.

The real test is what happens when something fails.

Can you inspect the request?

Can you identify the response?

Can you replay the submission?

If the answer is yes, you've built something that's much easier to support in production.

Because the goal isn't simply to send data.

It's to make sure valuable data never disappears without a trace.

How do you handle failed API requests in your WordPress projects?

Do you log every request, implement retries, or rely on external monitoring? I'd love to hear how other developers approach production integrations.

DEV Community: Rahul Sharma

CF7 to Trello: Cards Not Being Created Every Cause Explained

Cause 1: API Key and Token Confusion

Cause 2: Using Board ID Instead of List ID

Cause 3: The Card Description Can Only Hold One Mapped Field in Free Plugins

Cause 4: Token Expired or Insufficient Scope

Connecting CF7 to Trello Directly

Quick Diagnosis

CF7 to ClickUp Tasks Not Being Created - Four Causes and How to Fix Each

Cause 1: Field Type Mismatch - the FIELD_010 Error

Cause 2: Wrong Location in ClickUp's Four-Level Hierarchy

Cause 3: ClickUp API Token vs OAuth - Scope Issues

Cause 4: Custom Fields Locked Behind a Pro Paywall

Connecting CF7 to ClickUp Directly

Quick Diagnosis

CF7 to Slack Notifications Not Working - What Is Actually Broken

Reason 1: You Are Using a Legacy Slack Webhook URL

Reason 2: The Dedicated Plugin Is Abandoned

Reason 3: The Webhook URL Is Correct But the Payload Format Is Wrong

How to Connect CF7 to Slack Without a Dedicated Plugin

Reason 4: Slack Rate Limiting or App Permissions

Quick Diagnosis

CF7 to Notion Broke on August 11, 2026 - Here Is Exactly What Happened

The Root Cause: Missing Bearer Prefix in the Authorization Header

If You Are on Plugin Version 1.6.2 or Earlier

The PHP 9 Breaking Change Also In This Plugin

The Broader Lesson: External API Enforcement Changes Break Integrations Silently

Connecting CF7 to Notion Directly

Quick Reference

CF7 REST API Returns `wpcf7_forbidden` 403 - Why It Happens and How to Fix It

The Two Endpoints Are Not the Same

Cause 1: Calling the GET Endpoint Without Authentication

Cause 2: Missing Required Hidden Fields on the Feedback Endpoint

Cause 3: Nginx Redirect Misconfiguration

The Headless CF7 Integration Pattern That Avoids All of This

Quick Reference

CF7 REST API Returns `rest_no_route` 404 Every Cause Explained

What rest_no_route Actually Means

Cause 1: Wrong Form ID in the URL

Cause 2: WP Rocket Caching the REST API Response

Cause 3: .htaccess or Nginx Misconfiguration

Cause 4: HTTP to HTTPS Redirect Intercepting the API Request

Confirming the Route Is Actually Registered

A Different Architecture: Skip the REST API Dependency

Quick Diagnosis Checklist

CF7 to GetResponse Not Adding Contacts - What Is Actually Wrong

Reason 1: GetResponse Deprecated Their API - The Plugin Still Uses the Old Endpoint

Reason 2: No Error Logging in the Plugin

Reason 3: Field Shortcode Placement Bug

The GetResponse API V3 Direct Integration

Quick Checklist

CF7 + Zoho CRM: New Leads Overwriting Existing Records Instead of Creating New Ones

Why the Plugin Overwrites Records Instead of Creating New Ones

How Zoho's Duplicate Check Actually Works

When You Genuinely Need Always-Create Behaviour

Controlling This With a Direct API Integration

Fixing the Duplicate Check in Zoho First

Summary

Your Contact Form Created the Deal... Just in the Wrong Pipeline

HTTP 200 doesn't mean "problem solved"

The payload decides the destination

Mapping should follow the business process

What I check before deploying

Where Contact Form to API helps

Final thoughts

Contact Form 7 and Pipedrive Not Talking? Debug the Integration, Not the Form

The form isn't the entire workflow

My first rule: Never assume the API received the data

Common reasons integrations fail

Authentication problems

Incorrect endpoint

Payload mismatch

Network or timeout issues

Missing request visibility

The integration layer deserves more attention

Building a more resilient workflow

Where Contact Form to API fits

Final thoughts

Your API Worked Perfectly… It Just Created the Wrong CRM Record

The API did exactly what it was told

Cause 1: Field Type Mismatch - the `FIELD_010` Error

The Root Cause: Missing `Bearer` Prefix in the Authorization Header

What `rest_no_route` Actually Means

Cause 3: `.htaccess` or Nginx Misconfiguration