DEV Community: Rahul Sharma

CF7 Bearer Token vs API Key vs Basic Auth: When to Use Which

Rahul Sharma — Thu, 01 Oct 2026 07:19:21 +0000

You are configuring your Contact Form 7 form to send data to an external API. You open the plugin's authentication settings and see three options: Basic Auth, API Key, and Bearer Token.

Which one do you choose?

The answer depends entirely on what the target API expects. Using the wrong method is one of the most common causes of 401 errors, and it is entirely preventable. This guide explains each method, when to use it, and how to configure it correctly.

The Three Authentication Methods at a Glance

Method	How It Works	Security Level	Best For
Basic Auth	Username and password encoded in Base64	Low	Legacy systems, simple integrations, testing
API Key	A static key passed in a header or query parameter	Medium	Internal APIs, simple token-based auth
Bearer Token	A token (often JWT) passed in the Authorization header	Medium-High	Modern APIs, OAuth 2.0 flows, expiring tokens

Basic Auth: Simple but Limited

Basic Auth is the oldest and simplest authentication method. You send a username and password with every request, encoded in Base64.

How it works:

The credentials are combined as username:password and encoded. The request header looks like this:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

When to use it:

Basic Auth is appropriate for legacy systems that were built before modern authentication standards existed. It is also useful for quick testing and debugging because it requires no token generation or refresh logic.

When to avoid it:

Basic Auth is not inherently secure. The Base64 encoding is not encryption. Anyone who intercepts the request can decode the credentials in seconds. For production integrations, especially those handling sensitive customer data, a more secure method is strongly recommended.

Common use case in CF7 integrations:

Zendesk uses Basic Auth for its API. The username format is email/token, and the password is your API token. This is a case where Basic Auth is the required method, not a choice. For a full walkthrough of Zendesk authentication, see this guide on Contact Form 7 API authentication errors.

API Key: Simple and Static

An API Key is a static token that identifies your application or account. Unlike Bearer tokens, API keys typically do not expire. You generate them once and use them indefinitely.

How it works:

The key can be passed in several ways, depending on the API. Common locations include:

Authorization header: Authorization: YOUR_API_KEY
Custom header: X-API-Key: your-key-here
Query parameter: ?api_key=your-key-here

The plugin supports custom header configuration, so you can place the API key wherever the target API expects it.

When to use it:

API Keys are common for internal APIs, simple integrations, and services where the key identifies the application rather than a specific user. HubSpot private apps, for example, use an access token that functions like an API key.

Security considerations:

API keys provide authorization but not authentication. This means the key grants access to resources, but it does not verify who is making the request. If the key is intercepted, anyone can use it. Store API keys in environment variables or secure configuration, never in version control.

Bearer Token: Modern and Expiring

Bearer Token authentication is the most common method for modern APIs. The token is typically a JSON Web Token (JWT) or an OAuth 2.0 access token.

How it works:

You first obtain a token from the API's authentication endpoint. Then you include that token in the Authorization header:

Authorization: Bearer your-token-here

The word "Bearer" means that whoever holds the token can use it. The token itself is a cryptic string that proves your identity.

When to use it:

Bearer Tokens are the standard for OAuth 2.0 flows. If the API documentation mentions OAuth, access tokens, or token expiration, you need Bearer Token authentication. This is common with enterprise platforms like Salesforce, Google Workspace, and Microsoft 365.

Token expiration:

Unlike API keys, Bearer tokens expire. HubSpot access tokens, for example, expire after 30 minutes (1800 seconds). When a token expires, you need to refresh it using a refresh token.

This is where the plugin's OAuth add-on becomes valuable. The free version does not support automatic token renewal. The PRO add-on handles this automatically, refreshing tokens in the background so your integrations continue running without interruption.

Common use case in CF7 integrations:

HubSpot private apps use Bearer Token authentication. You generate a token in HubSpot's private app settings and paste it into the plugin's Bearer Token field. The Community forum confirms this is the standard approach for HubSpot integrations.

How to Choose: A Decision Framework

Step 1: Check the API documentation.

This is non-negotiable. The API documentation tells you exactly which authentication method it requires. Look for sections labeled "Authentication," "Authorization," or "API Keys."

Step 2: Match the method to the API's requirements.

API Says	Use This Method
"Basic Auth" or "username/password"	Basic Auth
"API Key" or "X-API-Key"	API Key
"Bearer Token" or "OAuth 2.0"	Bearer Token
"JWT" or "access token"	Bearer Token

Step 3: Consider the security requirements.

If the API supports multiple methods, choose the most secure one. Bearer Tokens with expiration are generally more secure than static API keys, which are more secure than Basic Auth.

Step 4: Test with the simplest method first.

If you are debugging a connection issue, start with Basic Auth or API Key. These are easier to configure and have fewer moving parts. Once the connection works, switch to the more secure method if needed.

Configuring Authentication in the Plugin

The plugin provides header input fields where you configure authentication manually.

For Basic Auth:

You need to Base64-encode your credentials before pasting them into the header field. The plugin does not execute PHP code in the header textarea, so you must encode the string externally.

For API Key:

Add a custom header with the API key. The exact header name depends on the API. Some use Authorization, others use X-API-Key, and some use api-key.

For Bearer Token:

Add the Authorization header with the value Bearer your-token-here. If your token expires, you will need to update it manually unless you use the PRO add-on with automatic token refresh.

Common Mistakes to Avoid

Using Bearer Token for an API that expects Basic Auth.

This is the most common 401 error cause. If the API documentation says "Basic Auth" and you send Authorization: Bearer, the request will be rejected.

Forgetting the "Bearer" prefix.

The header value must be Bearer token-here, not just token-here. The prefix tells the API how to interpret the token.

Using an expired token.

Bearer tokens expire. If your integration suddenly stops working after previously working fine, the token may have expired. Check the token's expiration settings in the API's dashboard.

Hardcoding credentials in the header without encoding.

For Basic Auth, the credentials must be Base64 encoded. Sending plain username:password will fail.

For a deeper dive into JSON structure mapping and header configuration, read this guide on Contact Form 7 JSON mapping.

Beyond Authentication: One Form, Multiple Destinations

Once your authentication is configured correctly, you might want to send the same form submission to multiple tools: a CRM, an email marketing platform, or a help desk system.

A good connector plugin supports multiple API integrations from a single form submission. You can create a CRM contact, send an SMS via Twilio, and create a Zendesk ticket, all from one CF7 submission, without Zapier. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

Check the API documentation first. The API tells you which method it requires. Guessing leads to 401 errors.

Basic Auth is for legacy systems and testing. It is simple but not secure. Use it when the API requires it, not by choice.

API Keys are for static integrations. They do not expire, which is convenient but less secure. Store them carefully.

Bearer Tokens are for modern APIs. They expire, which is more secure but requires refresh logic. The PRO add-on handles this automatically.

Match the header format exactly. Bearer, Basic, and custom prefixes are not interchangeable. One wrong character means a failed request.

With the right authentication method, correct header formatting, and an understanding of token lifecycle, your CF7 form will connect to any API reliably.

CF7 Submit Button Stays Disabled After 422 API Response: A Complete Troubleshooting Guide

Rahul Sharma — Wed, 30 Sep 2026 08:08:48 +0000

You have built a Contact Form 7 form. You have connected it to an external API through a connector plugin. When the API returns a successful response, everything works perfectly the form submits, the button resets, and the user sees a confirmation message.

But when the API returns a 422 Unprocessable Entity error, something strange happens. The form appears to hang. The submit button stays greyed out and disabled. The user cannot retry. They cannot correct their input. They are stuck.

This is a frustrating and often misunderstood problem. The good news is that it has a clear cause and several possible fixes. This guide walks through the exact debugging process and verified solutions.

Understanding What Happens on a 422 Response

When a user clicks the CF7 submit button, several things happen in sequence:

CF7 validates the form fields on the client side.
CF7 sends the submission to WordPress via AJAX.
The connector plugin intercepts the submission and sends a request to your external API.
The API returns a response — either success or an error.
CF7 receives the result and updates the UI accordingly.

A 422 response means the API received the request but could not process it. This is common when a required field is missing, a value is in the wrong format, or a validation rule fails on the API side.

The problem occurs at step 5. CF7 expects a clean success or failure signal. When the connector plugin passes through a 422 response without properly translating it into CF7's expected format, CF7 does not know how to reset the form. The submit button remains in its disabled state.

Failure #1: The Plugin Passes Through the Raw 422 Response

What you see: The form hangs. The submit button stays disabled. No error message appears. The browser console may show a failed AJAX request with a 422 status code.

Why it happens: CF7 expects a JSON response with a specific structure. It looks for a status property with a value of mail_sent, mail_failed, validation_failed, or spam. When the connector plugin passes through the raw API response which has a different structure CF7 does not recognize it. The JavaScript that re-enables the submit button never runs.

The fix:

Option A: Check your plugin's error handling settings. Some connector plugins have an option to "Return CF7-compatible response" or "Handle API errors gracefully." Enable this option if available. This tells the plugin to translate API errors into a format CF7 understands.

Option B: Use a custom hook to normalize the response. If your plugin does not have this option, you can add a filter to intercept the API response and reformat it before CF7 processes it. Add this to your theme's functions.php:

add_filter('cf7_to_api_response', 'normalize_422_response', 10, 2);
function normalize_422_response($response, $form_data) {
    if (isset($response['code']) && $response['code'] === 422) {
        return [
            'status' => 'validation_failed',
            'message' => 'The form could not be submitted. Please check your input.',
            'invalid_fields' => []
        ];
    }
    return $response;
}

Note: The exact filter name depends on your connector plugin. Check the plugin documentation for the correct hook.

For a deeper dive into JSON structure mapping and error response handling, read this guide on Contact Form 7 JSON mapping.

Failure #2: JavaScript Error Prevents Button Reset

What you see: The form hangs. The browser console shows a JavaScript error, often related to undefined or cannot read property of null.

Why it happens: When the API returns a 422, the connector plugin may attempt to display error messages for specific fields. If the API response references a field name that does not exist in the CF7 form, the JavaScript fails. This prevents the button reset code from running.

The fix:

Step 1: Open your browser's developer console. Look for red error messages. Note the exact error and the file where it occurs.

Step 2: Check field name alignment. Compare the field names in your API request with the field names in your CF7 form. A common mistake is using your-email in the form but email in the API mapping. When the API returns an error about email, the plugin cannot find a matching field and crashes.

Step 3: Disable error message display temporarily. In your connector plugin settings, turn off the option to display API error messages inline. This prevents the JavaScript from attempting to map errors to fields. The form will still fail, but the button should reset.

Failure #3: The API Returns 422 Without a Recognized Error Format

What you see: The form hangs. The plugin logs show a 422 response, but the response body does not contain field-specific errors.

Why it happens: Some APIs return a generic 422 response without specifying which field caused the problem. The connector plugin may expect a structured error format and fail when it does not receive one.

The fix:

Option A: Configure a fallback error message. In your plugin settings, set a generic error message to display when the API returns an unrecognized error format. This gives the user feedback and allows the form to reset.

Option B: Add a timeout to the AJAX request. If the API does not return a recognizable response, the JavaScript may wait indefinitely. Add a timeout to force the form to reset after a set period. This can be done with a small JavaScript snippet:

document.addEventListener('wpcf7submit', function(event) {
    setTimeout(function() {
        var submitButton = document.querySelector('.wpcf7-submit');
        if (submitButton && submitButton.disabled) {
            submitButton.disabled = false;
            submitButton.removeAttribute('disabled');
        }
    }, 5000);
}, false);

This snippet waits five seconds after a submit event and force-enables the button if it is still disabled. It is a workaround, not a fix, but it prevents users from being permanently stuck.

Failure #4: The Plugin Does Not Reset the Form on API Failure

What you see: The form hangs specifically when the API returns an error. When the API succeeds, the form resets correctly.

Why it happens: Some connector plugins only handle the success path. They do not have logic to reset the form when the API call fails. This is a plugin limitation, not a configuration issue.

The fix:

Option A: Update the plugin. Check if a newer version of your connector plugin addresses this issue. Many plugin developers fix error handling in later releases.

Option B: Report the issue. If the plugin is actively maintained, report the problem with specific details: the API endpoint, the 422 response body, and the observed behavior. Include screenshots of the console error.

Option C: Use a different submission mode. Some plugins offer a "redirect" mode instead of AJAX. In redirect mode, the form submission navigates to a new page. If the API fails, the user sees the error on the new page and can navigate back. This avoids the disabled button problem entirely.

The Debugging Checklist

Work through this sequence every time the submit button stays disabled:

Step	Action	What It Tells You
1	Open browser console	Is there a JavaScript error? Note the exact message.
2	Check the plugin's API Logs	What response did the API return? Is it a 422?
3	Inspect the 422 response body	Does it contain field-specific errors?
4	Compare field names	Do API error field names match CF7 field names?
5	Disable inline error display	Does the button reset when errors are not mapped to fields?
6	Check plugin documentation	Is there a setting for "CF7-compatible response"?
7	Test with a successful API call	Does the button reset correctly on success?

For a comprehensive breakdown of authentication and error handling across different APIs, see this guide on Contact Form 7 API authentication errors.

Preventing the Problem: Best Practices for API Error Handling

The best way to avoid the disabled button problem is to ensure your API integration is configured to handle errors gracefully.

1. Always map API errors to CF7-compatible responses. Your connector plugin should translate 422 responses into CF7's validation_failed status. If it does not, use a filter to do it manually.

2. Use consistent field names. Align your CF7 field names with the API's expected field names. This makes error mapping straightforward and prevents JavaScript crashes.

3. Test error scenarios explicitly. Do not just test the happy path. Submit forms with missing required fields, invalid email formats, and values that violate API rules. Verify that the submit button resets in every case.

4. Set a fallback error message. Even if the API returns an unrecognized error format, the user should see a generic message and be able to retry.

5. Monitor your plugin logs. The API Logs page shows every request and response. Review it regularly to catch error handling issues before users report them.

Beyond Error Handling: One Form, Multiple Destinations

Once your error handling is solid, you might want to send the same form submission to multiple tools: a CRM, an email marketing platform, or a help desk system.

Key Takeaways

A 422 response means the API received the request but could not process it. This is a validation error, not a connection error.

CF7 expects a specific response structure. When the connector plugin passes through a raw API error, CF7 does not know how to reset the form.

JavaScript errors can prevent the button from re-enabling. Check the browser console for errors related to field mapping.

A fallback error message and a timeout script can prevent users from being permanently stuck. These are workarounds, not fixes, but they improve the user experience.

The best fix is to configure your plugin to return CF7-compatible responses. Check the plugin settings for an option like "Return CF7-compatible response" or use a filter to normalize the response.

Test error scenarios explicitly. Do not assume the form will behave correctly when the API fails. Verify it.

With proper error handling configuration, consistent field naming, and a fallback mechanism, your CF7 form will reset correctly after a 422 response. Users will see a clear error message and be able to retry, instead of being stuck with a disabled button.

CF7 to Odoo ERP Not Creating Leads: A Complete Troubleshooting Guide

Rahul Sharma — Tue, 29 Sep 2026 09:43:29 +0000

You have configured your Contact Form 7 form to create leads in Odoo. You have entered your Odoo URL, database name, and API credentials. And yet, no leads appear in your Odoo CRM after a form submission.

This is a frustratingly common problem. The good news? The issue is almost always one of four things, and each has a clear fix. This guide walks through the exact debugging process, common error patterns, and verified solutions.

Understanding the Data Flow

When a user submits your CF7 form with Odoo lead creation enabled, here is what should happen:

User submits form → Plugin captures data → API request sent to Odoo → Lead created

Odoo supports multiple API protocols depending on your version. The most common are XML-RPC (older versions) and JSON-RPC (all versions), with newer REST endpoints available in Odoo 17+. Your integration plugin handles the protocol details, but you need to ensure the payload matches what Odoo expects.

Your first diagnostic tool is the plugin's API Logs. It shows whether a request was sent, the exact JSON payload, and the response from Odoo. If no request appears in the logs, the problem is on the WordPress side. For a deeper breakdown of that specific scenario, see this guide on Contact Form 7 data not reaching the API.

Failure #1: Invalid Field Error (KeyError: 'is_company')

What you see: An error in Odoo's server logs referencing KeyError: 'is_company' or ValueError: Invalid field 'is_company' on model 'crm.lead'.

Why it happens: This is a known issue with some Odoo integration plugins. The plugin is sending a field called is_company to the crm.lead model, but that field does not exist on that model.

In Odoo, is_company is a field on the res.partner model, not on crm.lead. When you create a lead, Odoo may automatically create or link a partner record, but the is_company flag belongs to the partner, not the lead itself.

The fix:

Option A: Update the plugin. If you are using a plugin with this known bug, check for a patch or update. In one reported case, the developer released version 3.3.1 specifically to fix this issue. Update your plugin and retry.

Option B: Remove the field from your mapping. If updating is not possible, check your field mapping configuration. If you have mapped any CF7 field to is_company, remove that mapping. This field is not required for lead creation and should not be sent.

How to verify: After updating or removing the mapping, submit a test form. Check Odoo's logs and your CRM. If the lead appears, the issue is resolved.

Failure #2: Missing Required Field (Name)

What you see: An error message stating: "The operation cannot be completed: Create/update: a mandatory field is not set. Model: Lead/Opportunity (crm.lead), Field: Opportunity (name)".

Why it happens: The name field is mandatory for the crm.lead model in Odoo. Every lead must have a title or name. If your CF7 form does not include a field mapped to name, or if that field is left empty, Odoo will reject the request.

The fix:

Step 1: Verify your mapping. Ensure at least one CF7 field is mapped to the Odoo name field. This could be a subject field, a concatenation of name and company, or a generic "Website Lead" title.

Step 2: Use a hidden field if needed. If your form does not have a natural field for the lead name, add a hidden field with a default value. For example:

[hidden lead-title default:get "Website Lead"]

Or use a static value:

[hidden type "lead"]

As demonstrated in a WordPress support thread, adding a hidden field with a default value and mapping it to the Odoo field works reliably.

Step 3: Ensure the field is never empty. If you are using a user-filled field for the lead name, make it required in CF7. If you want to allow it to be empty, use a hook to inject a fallback value before submission.

Failure #3: Connection Refused (Port Blocked)

What you see: An error message stating "Connect error: Connection refused (111)" or similar connection failure.

Why it happens: Your WordPress hosting server is blocking outbound requests to Odoo's port (typically 8069 or 443). This is a common security measure on shared hosting environments.

The fix:

Step 1: Contact your hosting provider. Ask them to open outbound cURL requests to Odoo's port. In one reported case, the user's hosting provider had blocked port 8069. After opening it, the integration worked immediately.

Step 2: Verify with Postman. Before blaming the plugin, test the connection directly. Use Postman to send a POST request to your Odoo instance. If that works but the plugin does not, the issue is likely the hosting firewall blocking the specific request path.

Step 3: Check your Odoo URL. Ensure you are using the correct URL format. For Odoo Online, it should be https://yourcompany.odoo.com. For self-hosted, it should be https://yourdomain.com:8069 or your configured port.

Failure #4: Authentication Failure

What you see: A 401 Unauthorized or 403 Forbidden response in the plugin logs.

Why it happens: Odoo's authentication is strict. The plugin is either using the wrong credentials, or the user account lacks permission to create leads.

The fix:

Step 1: Verify your credentials. Odoo requires:

Database name (for multi-database setups)
Username (your Odoo login email)
Password or API Key (API keys are recommended for security)

Step 2: Create a dedicated API user. For production integrations, do not use your personal admin account. Create a dedicated "bot" user in Odoo with only the minimum permissions needed to create leads. Generate an API key for this user.

Step 3: Check user permissions. The user account must have permission to create records in the crm.lead model. Verify this in Odoo's Settings > Users & Companies > Users.

Step 4: Check Odoo plan restrictions. If you are using Odoo Online, the external API for write operations (like creating leads) may require a Custom plan for high-volume usage. Basic read operations work on all plans, but write access at scale may be restricted.

For a comprehensive breakdown of authentication errors across different APIs, see this guide on Contact Form 7 API authentication errors.

The Debugging Checklist

Work through this sequence every time a lead fails to create:

Step	Action	What It Tells You
1	Check the plugin's API Logs	Was a request sent? If not, the problem is in WordPress.
2	Inspect the Response Code	401/403 = Auth issue. 422 = Field validation issue. 500 = Odoo server error.
3	Check Odoo's server logs	Look for specific KeyError or ValueError messages.
4	Test with a minimal payload	Hardcode values (name, email) to isolate field mapping issues.
5	Verify field mapping	Ensure `name` is mapped. Remove any `is_company` mapping.
6	Test connection with Postman	Isolates hosting firewall issues from plugin issues.

For a deeper dive into JSON structure mapping, read this guide on Contact Form 7 JSON mapping.

Beyond Odoo: One Form, Multiple Destinations

Once your Odoo integration works, you might want to send the same form submission to other tools: a CRM, an email marketing platform, or a help desk system.

A good connector plugin supports multiple API integrations from a single form submission. You can create an Odoo lead, add the contact to HubSpot, subscribe them to Mailchimp, and create a Zendesk ticket, all from one CF7 submission, without Zapier. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

The name field is mandatory. Every Odoo lead must have a title. Map a CF7 field to it, or use a hidden field with a default value.

Remove is_company from lead mappings. This field belongs to the partner model, not the lead model. Sending it to crm.lead causes a KeyError.

Check for blocked ports. Shared hosting often blocks outbound requests to Odoo's port. Contact your hosting provider if you see "Connection refused."

Use API keys, not passwords. Odoo 19 and newer versions support API keys as the preferred authentication method. Create a dedicated bot user for integrations.

Odoo is modular. The fields available on crm.lead depend on which modules are installed. A field that works in your Odoo instance may not exist in another.

Test in Postman first. If Postman works but the plugin does not, the problem is plugin configuration or hosting firewall. If Postman fails, the problem is Odoo configuration or credentials.

With the correct field mapping, valid authentication, and a quick check of the logs when things go wrong, your CF7-to-Odoo integration will create leads reliably every time.

CF7 + WPML Multilingual Forms Not Sending Correct Data to CRM: A Complete Troubleshooting Guide

Rahul Sharma — Mon, 28 Sep 2026 10:19:39 +0000

You have built a Contact Form 7 form on your WordPress site. You have translated it into multiple languages using WPML. You have configured the integration to send submissions to your CRM. And yet, when a visitor submits the form in a non-default language, the CRM either receives nothing, receives the wrong data, or creates records with missing fields.

This is one of the most frustrating multilingual integration problems. The form works. The translation displays correctly. But the data pipeline breaks somewhere between the form submission and the CRM record.

This guide walks through the exact causes, the debugging process, and verified solutions.

Understanding the WPML + CF7 + CRM Architecture

When you use WPML with Contact Form 7, the architecture involves multiple layers:

WPML Translation Layer → CF7 Form Rendering → Form Submission → API Plugin → CRM

Each layer introduces potential failure points. The most common issues fall into four categories:

Translation configuration problems (WPML not set up correctly for CF7)
Field mapping issues (CF7 field names not matching API expectations)
Pipe-separated value handling (dropdown options behaving unexpectedly)
Integration settings not replicated (plugin configuration missing on translated forms)

The WPML + CF7 Translation Setup: What You Need to Know

Before debugging CRM integration, you must verify that WPML is correctly translating your CF7 form. WPML provides an official add-on called WPML Multilingual for CF7 that handles the translation glue between the two plugins.

How It Should Work

According to WPML's official documentation, the recommended workflow is:

Build the form once in your site's default language.
Send the form for translation through WPML's translation dashboard.
Use the same shortcode on translated pages. WPML serves the translated version automatically based on the visitor's language.

The critical rule: Do not create separate forms for each language. Use one form, translated through WPML's system.

Common Translation Mistakes

Mistake 1: Creating separate forms per language. If you duplicate the form for each language, the API integration settings are also duplicated. Each form needs its own API configuration, and missing settings on any language's form will cause failures.

A WordPress forum user reported exactly this: their form worked in German but failed in English. The email sent correctly, but the Brevo (Sendinblue) CRM integration did not. The solution was to manually re-check the CRM list selection on the translated form's settings.

Mistake 2: Assuming translation is automatic for integration settings. WPML translates form tags, messages, and mail templates. It does not automatically replicate plugin integration settings. You must manually verify that your CRM integration is configured on each language version.

The Pipe-Separated Value Problem

This is the most subtle and damaging issue for multilingual CRM integrations.

What Pipe Syntax Does

Contact Form 7 supports pipe-separated values in dropdowns:

[select your-country "China" "India" "San Marino"]

With pipe syntax, you can display one label to the user but submit a different value:

[select your-country "China|CN" "India|IN" "San Marino|SM"]

The user sees "China" but the form submits "CN".

How WPML Handles This

According to WPML's official documentation, WPML Multilingual for CF7 translates the visitor-facing labels while keeping the submitted value canonical.

A French visitor sees "Chine" instead of "China". But the form submission, the email body, and your CRM receive the original English value "China" (or "CN" if you used pipe syntax).

Why This Breaks CRM Integrations

The problem occurs when:

You did not use pipe syntax in the original form.
WPML translates the label to "Chine".
The submitted value becomes "Chine" instead of "China".
Your CRM expects "China" (or a specific country code).
The CRM rejects the value, ignores it, or stores incorrect data.

The Fix

Always use pipe syntax for dropdown values that feed into a CRM.

Wrong	Right
`[select country "China" "India"]`	`[select country "China\

This ensures the submitted value remains stable regardless of the visitor's language. The CRM always receives the canonical value, while visitors see translated labels.

The Field Mapping Problem in Multilingual Contexts

Even when WPML works correctly, field mapping between CF7 and your CRM can fail.

Why Field Mapping Breaks

A field mapping problem is not a connection problem. The API can return a successful response while the data ends up in the wrong CRM fields.

Common scenarios:

Your CF7 field is named {% raw %}your-name, but the CRM API expects first_name.
Your form field is named company, but the CRM expects organization.
Your dropdown submits a label, but the CRM expects an ID.

The Translation Layer Analogy

Think of field mapping as a translation layer. The form field names and the CRM field names are not automatically the same. Your integration needs to explicitly translate:

company → organization
your-email → email_address
inquiry-type → lead_source

Without this mapping, the API may ignore the value, place it somewhere unexpected, or reject the request.

The Fix

Create a mapping table before configuring the API plugin:

Contact Form 7 Field	API Field	CRM Field
your-name	name	Name
your-email	email	Email
your-phone	phone	Phone
company	organization	Company
inquiry-type	lead_source	Lead Source

Verify each mapping in the plugin's JSON payload configuration. Test with a hardcoded value first, then replace with CF7 tags. For a deeper dive into JSON structure mapping, read this guide on Contact Form 7 JSON mapping.

The Integration Settings Not Replicated Problem

This is specific to WPML's translation workflow.

What Happens

When WPML translates a CF7 form, it creates a translated version of the form. However, third-party plugin settings are not automatically replicated to the translated form.

A WordPress user described this exactly: their Brevo integration worked in French but failed in English. The PHP debug log showed no errors related to the form itself. The email sent fine. But the CRM contact was not created.

The root cause: the Brevo list selection was not enabled on the English version of the form.

The Fix

For every translated form version:

Open the translated form in CF7 editor.
Navigate to your API plugin's settings tab for that form.
Manually verify that all integration settings are enabled and configured.
Save the form.

WPML does not sync plugin-specific settings across translations. You must do this manually.

The CF7 Not Sending in Translated Language Problem

Sometimes the problem is not the CRM integration at all. The form itself fails to submit in the translated language.

The REST API URL Issue

WPML has a known issue where the REST API URL for CF7 includes the language parameter incorrectly:

/wp-json/?lang=en/contact-form-7/v1/contact-forms/11187/feedback

This causes a 404 error, and the form never submits. For a full breakdown of data not reaching your API, see this guide on Contact Form 7 data not reaching the API.

The Fix

Add this to your theme's functions.php:

add_filter( 'wpcf7_load_js', '__return_false' );

Or switch WPML's URL format from "language name added as a parameter" to "different languages in directories".

This is a WPML bug, not a plugin issue. But it prevents the form from submitting, which means no data reaches your CRM.

The Debugging Checklist

Work through this sequence for every multilingual CRM integration failure:

Step	Action	What It Tells You
1	Test the form in the default language	Does the CRM receive data? If yes, the problem is translation-specific.
2	Test the form in a translated language	Does the form submit at all? If not, check the REST API URL issue.
3	Check the plugin's API Logs	Was a request sent? What was the response code?
4	Inspect the JSON payload in logs	Are the field values correct? Are translated values being sent?
5	Verify pipe syntax in dropdowns	Are labels translated while values stay canonical?
6	Check integration settings on translated form	Are CRM settings enabled for this language version?
7	Verify field mapping	Do CF7 field names match API expectations?

Beyond CRM: One Form, Multiple Destinations

Once your multilingual CRM integration works, you might want to send the same submission to other tools: an email marketing platform, a help desk system, or an SMS notification service.

A good connector plugin supports multiple API integrations from a single form submission. You can create a CRM contact, send an SMS via Twilio, create a Zendesk ticket, and subscribe them to Mailchimp, all from one CF7 submission, without Zapier. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

Use pipe syntax for all dropdown values. This keeps submitted values stable across languages while visitors see translated labels.

Do not create separate forms per language. Use WPML's official translation workflow. Separate forms mean separate integration settings and more failure points.

Manually verify integration settings on every translated form. WPML does not sync third-party plugin settings across translations.

Check the REST API URL if forms do not submit in translated languages. This is a known WPML bug with a simple fix.

Field mapping is not a connection problem. The API can succeed while data goes to the wrong fields. Always verify the mapping table.

Test in the default language first. If it works there, the problem is translation-specific. If it fails there too, the problem is in your API configuration.

With correct pipe syntax, verified integration settings on every translated form, and careful field mapping, your CF7 + WPML + CRM integration will deliver accurate data in every language.

CF7 to Twilio SMS Not Sending After Form Submit: A Complete Troubleshooting Guide

Rahul Sharma — Fri, 25 Sep 2026 12:48:03 +0000

You have configured your Contact Form 7 form to trigger an SMS notification through Twilio. You have entered your Account SID and Auth Token. And yet, no text message arrives on your phone after a form submission.

Understanding the Data Flow

When a user submits your CF7 form with Twilio SMS notifications enabled, here is what should happen:

User submits form → Plugin captures data → POST request sent to Twilio API → SMS delivered

When it breaks, the failure happens at one of the last two stages. Your first diagnostic tool is the Twilio Console logs. It shows whether a request was sent at all, the exact message content, and the delivery status.

If no request appears in Twilio logs, the problem is on the WordPress side. For a deeper breakdown of that specific scenario, see this guide on Contact Form 7 data not reaching the API.

Failure #1: The Phone Number Format Problem

What you see: SMS History shows "sent" but no message arrives. Or the plugin throws a validation error.

Why it happens: Twilio requires phone numbers in E.164 format. This means a plus sign, country code, and the full number with no spaces or dashes. For example: +14155552671.

A common mistake is entering a domestic number without the country code. The plugin may accept it, but Twilio will reject or silently fail to deliver the message.

The fix:

Setting	Correct Value
To (recipient)	`+14155552671` (country code + number)
From (Twilio number)	`+14155552671` (your active Twilio number)

How to verify: Send a test SMS directly from your Twilio Console. If that works but the plugin does not, the issue is likely the number format in the plugin settings.

Failure #2: The Tags Not Working Problem

What you see: The SMS sends and arrives perfectly when using plain text. But when you add CF7 tags like [your-name] or [your-message], the message never arrives. Or it arrives empty.

Why it happens: This is a known issue in some CF7-to-Twilio integrations. The tags are not being replaced with actual form data before the SMS is sent. Possible causes include a plugin bug, a conflict with another form plugin, or an issue with how the tags are formatted.

The fix:

Option A: Check the SMS History tab. Some plugins have an SMS History feature that shows the actual content sent. If the history shows the raw tags (e.g., [your-name]) instead of the replaced values, the tag replacement is failing.

Option B: Test with a minimal payload. Create a simple form with just one text field. Add that field's tag to the SMS content. Submit the form and check if the tag is replaced. If not, the issue is in the plugin.

Option C: Contact the plugin developer. This is a known bug in some integrations. The developer may have a pre-release version that fixes the tag replacement issue. Provide them with your CF7 version, plugin version, and screenshots of the SMS History showing the unreplaced tags.

For a deeper dive into how field mapping works, read this guide on Contact Form 7 JSON mapping.

Failure #3: The Twilio Account Configuration Problem

What you see: No SMS record appears in Twilio logs at all. The form submits successfully, but Twilio never receives a request.

Why it happens: The plugin cannot authenticate with Twilio, or the Twilio number is not properly configured for SMS.

The fix:

Step 1: Verify your credentials. Go to Twilio Console homepage and confirm your Account SID and Auth Token are correct. Copy them fresh into the plugin settings.

Step 2: Check your Twilio number. Navigate to Phone Numbers > Manage > Active Numbers. Verify that your Twilio number has SMS capabilities. Numbers that cannot send SMS will not work for this integration.

Step 3: Check for trial account restrictions. If you are using a Twilio trial account, you can only send SMS to verified phone numbers. Add your recipient number to the verified list in Twilio Console, or upgrade your account.

Step 4: Check A2P 10DLC registration. As of September 2023, US carriers require A2P 10DLC registration for business SMS. If your registration is incomplete or failed, carriers will block your messages.

Failure #4: The API Error Response Problem

What you see: A specific error code appears in the plugin settings when you enable error display, or in Twilio logs.

Why it happens: Twilio is returning an error that tells you exactly what is wrong.

Common Twilio error codes and fixes:

Error Code	Meaning	Fix
21604	"To" phone number is required	Add the recipient phone number in the plugin settings
14101	Invalid "To" attribute	Check number format and verify the number if using a trial account
4XX	General API error	Look up the specific code in Twilio's error documentation

The fix: Enable the "Show Error Message" option in your plugin settings. Submit the form again. Copy the exact error message and look it up in Twilio's API error documentation.

For a full breakdown of timeout issues that may affect SMS delivery, refer to this article on Contact Form 7 API timeout.

The Debugging Checklist

Work through this sequence every time an SMS fails to send:

Step	Action	What It Tells You
1	Check Twilio Console logs	Was a request sent? If not, the problem is in WordPress.
2	Check plugin SMS History	What content was sent? Are tags replaced?
3	Enable error display	What specific error is returned?
4	Test with hardcoded values	Isolates tag issues from configuration issues.
5	Verify number format	E.164 format: +[country code][number]
6	Check trial account limits	Are you sending to a verified number?

Beyond SMS: One Form, Multiple Destinations

Once your Twilio SMS integration works, you might want to send the same form submission to other tools: a CRM, an email marketing platform, or a help desk system.

A good connector plugin supports multiple API integrations from a single form submission. You can send an SMS via Twilio, create a Zendesk ticket, add the contact to HubSpot, and subscribe them to Mailchimp, all from one CF7 submission, without Zapier. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

Phone numbers must be in E.164 format (+14155552671). Domestic-only formats will fail.

Tags not working is a known bug in some integrations. Test with plain text first, then add tags one at a time.

Twilio trial accounts can only send to verified numbers. Upgrade or verify your recipients.

A2P 10DLC registration is now required for US business SMS. Incomplete registration means blocked messages.

Twilio Console logs are your best debugging tool. Check them first, every time.

With the right number format, correct account configuration, and a quick check of the logs when things go wrong, your CF7-to-Twilio SMS notifications will work reliably every time.

Debugging CF7 to Zendesk Ticket Creation Failures: A Complete Troubleshooting Guide

Rahul Sharma — Thu, 24 Sep 2026 12:49:12 +0000

Integrating Contact Form 7 (CF7) with Zendesk's Ticketing API is a powerful way to automate lead capture and support ticket creation. However, this integration frequently fails due to subtle configuration errors in authentication or payload structure. This guide walks through the exact debugging process, common error codes, and verified fixes.

Understanding the Data Flow

Before diving into fixes, it helps to understand what happens when your CF7 form is submitted:

CF7 captures the form submission.
A connector plugin intercepts the data.
The plugin sends a POST request to Zendesk's /api/v2/tickets endpoint.
Zendesk processes the request and creates a ticket—or returns an error.

Most failures occur at steps 3 and 4. The plugin's API Logs page is your primary debugging tool; it shows the exact request sent and the response received. If you're seeing empty logs, refer to our guide on Contact Form 7 data not reaching the API for deeper troubleshooting.

Common Failure Point 1: 401 Unauthorized (Authentication)

The single most frequent cause of failure is incorrect Zendesk authentication configuration.

The Symptom: Your API logs show a 401 Unauthorized response.

The Cause: Zendesk does not use Bearer tokens for standard API token authentication. It uses Basic Auth with a specific username format that is easy to get wrong.

The Fix (Three Critical Steps):

Auth Type: In the plugin, set Authorization type to Basic Auth.
Username Format: Enter your Zendesk admin email with /token appended. For example: admin@yourcompany.com/token. The /token suffix is mandatory and is the most commonly forgotten step.
Password: Paste the API Token you generated in Zendesk Admin Center (Apps and integrations > APIs > Zendesk API).

Verification: After fixing this, submit a test form. You should now receive a different error code (likely 422) if other issues exist, which means authentication has been successfully resolved.

Common Failure Point 2: 422 Unprocessable Entity (Payload Structure)

Once authentication works, the next barrier is the JSON payload. Zendesk's Ticket API is strict about its schema.

The Symptom: You receive a 422 Unprocessable Entity response. The error message often references missing required fields like comment or requester.

The Cause: You are sending a flat JSON object with CF7 field names. Zendesk requires a specific nested structure within a root ticket object.

The Fix:

Your request body must follow this structure:

{
  "ticket": {
    "subject": "[CF7 Field: your-subject]",
    "comment": {
      "body": "[CF7 Field: your-message]"
    },
    "requester": {
      "name": "[CF7 Field: your-name]",
      "email": "[CF7 Field: your-email]"
    }
  }
}

Key requirements:

The root key must be ticket.
The comment.body field is required and cannot be empty.
The requester.email field is required to associate the ticket with a user.

Debugging Tip: Start with a minimal test payload using hardcoded values (e.g., "subject": "Test Ticket"). Once that succeeds, replace hardcoded values with your CF7 field placeholders one by one. For a deeper dive into JSON structure mapping, read our guide on Contact Form 7 JSON mapping.

Common Failure Point 3: Empty Required Fields

A subtle variant of the 422 error occurs when a CF7 form field that maps to a required Zendesk field is left empty by the user.

The Symptom: Tickets fail intermittently, often when users skip the "message" field.

The Cause: Zendesk's comment.body is required. If your CF7 form allows that field to be empty, the API call will fail.

The Fix (Two Options):

Make the field required in CF7: Enable the "Required" option on the relevant form field.
Set a default value: If you don't want to force users to fill it out, use a small custom hook to inject a fallback value before the form is submitted.

Example snippet (add to your theme's functions.php or a custom plugin):

add_action('wpcf7_before_send_mail', 'set_default_zendesk_description');
function set_default_zendesk_description($contact_form) {
    $submission = WPCF7_Submission::get_instance();
    if ($submission) {
        $data = $submission->get_posted_data();
        if (empty($data['your-message'])) {
            $data['your-message'] = 'No detailed description provided.';
            $submission->set_posted_data($data);
        }
    }
}

Common Failure Point 4: API Timeout

If your Zendesk instance is slow to respond or your server has strict timeout limits, the request may fail before completing.

The Symptom: Logs show a timeout error or the request never completes.

The Cause: Server-side timeout limits or Zendesk API rate limiting.

The Fix:

Increase PHP max_execution_time on your WordPress server.
Check Zendesk's API rate limits (typically 400 requests per minute for most plans).
Consider implementing a retry mechanism using the plugin's conditional logic features.

For a full breakdown of timeout issues, refer to our article on Contact Form 7 API timeout.

Recommended Debugging Workflow

Follow this sequence to isolate the problem efficiently:

Step	Action	What to Look For
1	Check the plugin's API Logs page	Is there a log entry? If empty, the request was never sent—check CF7 configuration.
2	Inspect the Response Code	401 = Auth issue. 422 = Payload issue. 500 = Zendesk server issue.
3	Enable Debug Mode in plugin settings	See the exact JSON payload sent and the full response body.
4	Test with minimal payload	Hardcode values to isolate whether the issue is structure or field mapping.
5	Verify field mapping	Ensure CF7 field names match exactly what you've entered in the plugin.

Extending the Integration: Multiple APIs and CRM Sync

Once Zendesk ticket creation works, you may want to send the same form submission to additional destinations—for example, a CRM like HubSpot or Salesforce, or a marketing tool like Mailchimp.

A capable connector plugin supports multiple API integrations from a single form submission. This means you can:

Create a Zendesk ticket.
Add the contact to HubSpot.
Subscribe them to Mailchimp.
Log the lead in Salesforce.

All from a single CF7 submission, without additional plugins or Zapier subscriptions.

Key Takeaways

Basic Auth with /token suffix is non-negotiable for Zendesk API token authentication.
The root JSON key must be ticket, with comment.body and requester.email as required nested fields.
The plugin's logging feature is your most valuable debugging asset—use it to see the raw request and response.
Start simple, then expand. A working hardcoded request proves connectivity; add field mappings incrementally.
No Zapier required. A dedicated connector plugin handles the integration natively, reducing cost and complexity.

Once these configuration layers are correct, your CF7 to Zendesk integration will reliably create tickets without the overhead of a dedicated connector or third-party automation service.

Why Your Contact Form Submissions Are Ruining Your CRM Data (And How to Fix Field Mapping)

Rahul Sharma — Wed, 23 Sep 2026 11:16:05 +0000

A Contact Form 7 integration can return a successful API response, create a CRM record, and still put the wrong data into the wrong fields.

That is one of the more frustrating integration bugs because, technically, nothing appears to be broken.

The form submits.

The API responds.

The CRM creates the record.

Yet when someone opens that record, the data is wrong.

The customer's company might appear as their job title. A phone number might end up in a custom text field. A dropdown value might be rejected or silently stored incorrectly.

This is usually a field-mapping problem, not a connection problem.

The API Request Can Succeed While the Data Is Still Wrong

When debugging a Contact Form 7 integration, developers often start with the HTTP response.

For example:

POST /api/contacts
200 OK

At first glance, everything looks good.

But HTTP 200 only tells you that the API accepted the request. It does not necessarily tell you that the values were mapped to the fields you intended.

Consider a simple Contact Form 7 form:

[text* customer-name]
[email* customer-email]
[tel customer-phone]
[text company]
[select inquiry-type "Sales" "Support" "Partnership"]

The submitted data might look like:

{
  "customer-name": "John Smith",
  "customer-email": "john@example.com",
  "customer-phone": "+1 555 123 4567",
  "company": "Example Inc",
  "inquiry-type": "Sales"
}

But the CRM API may expect something completely different:

{
  "name": "John Smith",
  "email": "john@example.com",
  "phone": "+1 555 123 4567",
  "organization": "Example Inc",
  "lead_source": "website"
}

The form field names and API field names are not automatically the same thing.

That translation layer is where field mapping becomes important.

Think of Field Mapping as a Translation Layer

A useful way to debug these integrations is to think about three separate layers:

Contact Form 7
      ↓
Submitted Form Data
      ↓
Field Mapping / Transformation
      ↓
API Payload
      ↓
CRM

A problem at any point can produce bad CRM data.

For example:

Form field:
company

API field:
organization

CRM field:
Company Name

The value may be identical, but the field identifiers are not.

Your integration needs to explicitly translate:

company → organization

Without that mapping, the API may ignore the value, place it somewhere unexpected, or reject the request.

Start by Comparing the Form With the API

Before changing code or debugging authentication, create a simple mapping table.

Contact Form 7	API Field	CRM Field
customer-name	name	Name
customer-email	email	Email
customer-phone	phone	Phone
company	organization	Company
inquiry-type	lead_source	Lead Source

This immediately exposes mismatches.

It also prevents a common mistake: assuming that the CRM's field label is the same as the API property name.

It often isn't.

For example, the CRM interface might display:

Company Name

while the API expects:

organization

The UI label is designed for humans.

The API field is designed for machines.

Your integration needs to know the latter.

JSON Mapping Is Where Many Integrations Go Wrong

For APIs that accept JSON, the payload should be treated as a contract.

For example:

{
  "name": "[customer-name]",
  "email": "[customer-email]",
  "phone": "[customer-phone]",
  "organization": "[company]"
}

The important part isn't just sending JSON.

It's sending the correct JSON structure.

A payload like this:

{
  "customer-name": "John Smith",
  "company": "Example Inc"
}

may be perfectly valid JSON but completely useless to an API expecting:

{
  "name": "John Smith",
  "organization": "Example Inc"
}

Valid JSON does not automatically mean valid API data.

That's an important distinction when troubleshooting form integrations.

Watch Out for Data Types

Field mapping isn't only about field names.

Data types matter too.

A form might provide:

Interested: Yes

while the API expects:

{
  "interested": true
}

Or a form might send:

Sales

while the CRM expects a specific option identifier:

{
  "lead_type": 123
}

The value may look correct to a human but still be invalid for the API.

Common examples include:

Text vs numeric IDs
"true" vs true
"false" vs false
Date strings vs timestamps
CRM option labels vs internal option IDs
Single values vs arrays
Empty strings vs null

These differences are easy to overlook because the form itself may work perfectly.

Dropdowns Deserve Extra Attention

Dropdowns are another common source of mapping problems.

Imagine your Contact Form 7 field contains:

[select* department "Sales" "Support" "Billing"]

Your CRM might not accept those exact strings.

Instead, its API could require something like:

{
  "department_id": 42
}

So the mapping isn't simply:

department → department

It becomes:

Sales → 42
Support → 43
Billing → 44

That is why developers should check the API documentation for accepted values instead of assuming that the visible form value is what the CRM expects.

Don't Debug the Wrong Layer

One of the biggest time-wasters in API integrations is debugging the connection when the connection isn't actually the problem.

A useful debugging sequence is:

1. Did the form submit?
        ↓
2. Was the webhook/API request triggered?
        ↓
3. What payload was actually sent?
        ↓
4. Did the API accept the request?
        ↓
5. What fields did the API actually process?
        ↓
6. What values appeared in the CRM?

If the API returns a successful response, don't immediately assume the integration is finished.

Inspect the payload.

Then inspect the resulting CRM record.

The difference between those two is often where the bug becomes obvious.

Log the Payload During Debugging

When troubleshooting a field-mapping issue, logging is extremely useful.

For example, temporarily record:

{
  "name": "John Smith",
  "email": "john@example.com",
  "organization": "Example Inc",
  "lead_source": "website"
}

Then compare it with the CRM record.

If the payload is already wrong, the problem is somewhere between the form and the API request.

If the payload is correct but the CRM record is wrong, investigate the API's field definitions, transformations, or response behavior.

This distinction can save a lot of unnecessary debugging.

Keep the Mapping Explicit

A maintainable integration shouldn't rely on assumptions such as:

form field name == API field name

Instead, make the relationship explicit:

CF7: customer-name
        ↓
API: name
        ↓
CRM: Name

CF7: company
        ↓
API: organization
        ↓
CRM: Company

This makes the integration easier to understand and much easier to troubleshoot when the form changes later.

It also helps when different CRM systems use different terminology.

What If You Have Multiple CRM Integrations?

This becomes even more important when one Contact Form 7 form sends data to multiple systems.

For example:

Contact Form 7
      ↓
 ┌────┴─────┐
 ↓          ↓
CRM A     CRM B

CRM A might expect:

{
  "organization": "Example Inc"
}

while CRM B expects:

{
  "company_name": "Example Inc"
}

The original form field can remain:

company

but each API request needs its own mapping.

This is one reason API-based form automation becomes useful for more complex WordPress setups. Instead of expecting every service to understand your form's field names, you control the payload sent to each destination.

For more background, the Contact Form 7 JSON mapping guide covers this part of the integration process in more detail.

Where Contact Form to API Fits

This is also where a tool such as Contact Form to API can be useful.

The important benefit isn't simply connecting Contact Form 7 to an API. The more important part is being able to control how the submitted form data is structured and mapped before it reaches the destination.

That matters when your CRM uses different field names, custom fields, specific values, or a payload structure that doesn't directly match your Contact Form 7 form.

For broader WordPress CRM integration considerations, see the Contact Form 7 CRM integration guide.

A Practical Field-Mapping Checklist

Before calling a Contact Form 7 → CRM integration complete, verify:

Does every required form field have a destination?
Are the API field names correct?
Are CRM field IDs different from their visible labels?
Are dropdown values accepted by the CRM?
Are numbers being sent as numbers where required?
Are booleans being sent as booleans?
Are dates in the format expected by the API?
Are empty fields handled correctly?
Does the JSON structure match the API documentation?
Does the actual CRM record match the submitted form?

And most importantly:

Don't stop debugging when you receive HTTP 200.

A successful HTTP response means the request was accepted. It doesn't prove that the business data ended up in the right place.

The Real Goal Is Correct Data, Not Just Successful Requests

A CRM integration has two different definitions of success.

The first is technical:

Request sent → API accepted it

The second is operational:

Form submitted
      ↓
Correct payload created
      ↓
API accepted it
      ↓
Correct CRM fields populated
      ↓
Sales team can use the data

The second outcome is what actually matters.

If your Contact Form 7 submissions are reaching the CRM but the records contain incorrect, missing, or misplaced values, the integration isn't necessarily broken at the connection level.

The mapping may be.

And once you start treating field mapping as a deliberate translation layer rather than an automatic process, these problems become much easier to diagnose.

CF7 to Freshdesk Tickets Not Being Created - Four Causes and Exact Fixes

Rahul Sharma — Tue, 22 Sep 2026 08:08:23 +0000

A developer documented a real CF7 to Freshdesk integration in a 2017 tutorial. The comments section became a support thread multiple people following the same code reported that "it just sends the email but no activity on Freshdesk." The author's debugging advice: use Postman to test the API directly, then print the PHP array to check the values.

That debugging advice is still the right starting point. Here are the four causes that produce the same symptom form submits, email arrives, no Freshdesk ticket.

Cause 1: Wrong Domain Format in the API URL

Freshdesk API calls require your full subdomain in the URL:

https://YOUR_SUBDOMAIN.freshdesk.com/api/v2/tickets

Where YOUR_SUBDOMAIN is the part before .freshdesk.com in your Freshdesk URL. If your Freshdesk account is at acmehelp.freshdesk.com, the API endpoint is:

https://acmehelp.freshdesk.com/api/v2/tickets

The most common mistake is entering just the subdomain (acmehelp) without the full domain, or using freshdesk.com without the subdomain prefix. Both produce a URL that either does not resolve or returns a generic Freshdesk error page rather than an API response.

Test your domain format:

curl -v "https://YOUR_SUBDOMAIN.freshdesk.com/api/v2/tickets" \
  -u "YOUR_API_KEY:X"

If you see a JSON response (even a 401), the URL format is correct. If you see an HTML page or a connection error, the domain format is wrong.

Cause 2: API Key Authentication Format Is Not Standard

Freshdesk uses HTTP Basic authentication but with a non-standard format. The username is your API key and the password is literally the letter X:

Authorization: Basic base64(YOUR_API_KEY:X)

This is different from most APIs. The API key goes in the username position. The password is always X not your actual password, not empty, literally the single character X.

Using wp_remote_post in PHP:

'headers' => [
    'Authorization' => 'Basic ' . base64_encode(FRESHDESK_API_KEY . ':X'),
    'Content-Type'  => 'application/json',
],

If you enter your email and password in the Basic auth fields instead of API_KEY:X, authentication will fail with a 401 even if the credentials are otherwise correct.

Find your Freshdesk API key: In Freshdesk, click your profile picture at the top right, then Profile Settings. The API Key appears at the bottom right of the page.

Cause 3: Required Fields Missing from the Ticket Payload

Freshdesk requires at minimum two fields for every ticket:

subject — the ticket title/subject line
email — the requester's email address

Without both, Freshdesk returns a 422 Unprocessable Entity with a validation error. If your plugin or custom code maps only the message body or only the name, the ticket creation fails.

A minimal valid Freshdesk ticket payload:

{
  "subject": "Enquiry from Jane Smith",
  "description": "Message content here",
  "email": "jane@example.com",
  "status": 2,
  "priority": 1
}

Freshdesk status codes:

1 = Open
2 = Pending
3 = Resolved
4 = Closed

Freshdesk priority codes:

1 = Low
2 = Medium
3 = High
4 = Urgent

For most CF7 contact form tickets, status: 2 (Pending) and priority: 1 (Low) are appropriate defaults.

Cause 4: The Hook `wpcf7_mail_sent` vs `wpcf7_before_send_mail`

The original tutorial code used wpcf7_mail_sent as the hook:

add_action('wpcf7_mail_sent', 'cf7_create_freshdesk_ticket', 0, 1);

wpcf7_mail_sent fires only after CF7 has successfully sent its notification email. If CF7's mail sending fails for any reason — SMTP configuration issues, email blocked by spam filter, missing mail configuration — this hook never fires and no Freshdesk ticket is created.

The more reliable hook for API integrations is wpcf7_before_send_mail:

add_action('wpcf7_before_send_mail', 'cf7_create_freshdesk_ticket');

This fires during the submission processing regardless of whether the email is sent successfully. For use cases where the Freshdesk ticket should always be created when someone submits the form, not only when the email delivery succeeds, use wpcf7_before_send_mail.

Complete CF7 to Freshdesk Implementation

add_action('wpcf7_before_send_mail', 'cf7_create_freshdesk_ticket');

function cf7_create_freshdesk_ticket($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']        ?? '');
    $message   = sanitize_textarea_field($data['your-message'] ?? '');

    if (empty($email)) return;

    $api_key   = defined('FRESHDESK_API_KEY')    ? FRESHDESK_API_KEY    : '';
    $subdomain = defined('FRESHDESK_SUBDOMAIN')  ? FRESHDESK_SUBDOMAIN  : '';

    $response  = wp_remote_post(
        "https://{$subdomain}.freshdesk.com/api/v2/tickets",
        [
            'headers' => [
                'Authorization' => 'Basic ' . base64_encode($api_key . ':X'),
                'Content-Type'  => 'application/json',
            ],
            'body'    => wp_json_encode([
                'subject'     => 'Enquiry from ' . $name,
                'description' => $message,
                'email'       => $email,
                'status'      => 2,
                'priority'    => 1,
            ]),
            'timeout' => 15,
        ]
    );

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

    $status = wp_remote_retrieve_response_code($response);
    error_log('[CF7->Freshdesk] Response: ' . $status . ' — ' . wp_remote_retrieve_body($response));
}

Store credentials in wp-config.php:

define('FRESHDESK_API_KEY',   'your-api-key-here');
define('FRESHDESK_SUBDOMAIN', 'yourcompany');

No-Code Alternative

Contact Form to API handles the Freshdesk API call from the WordPress dashboard. Configure:

Endpoint: https://yoursubdomain.freshdesk.com/api/v2/tickets
Method: POST
Authorization: Basic + base64 of YOUR_API_KEY:X
Body: JSON with subject, email, description, status, priority

The response is logged for every submission so you see the Freshdesk ticket ID or the exact validation error if something fails.

Quick Diagnosis

Error	Cause	Fix
Connection error / HTML response	Wrong domain format in URL	Use `https://SUBDOMAIN.freshdesk.com/api/v2/tickets`
`401 Unauthorized`	Wrong auth format	Use `API_KEY:X` as Basic auth, not email:password
`422 Unprocessable Entity`	Missing `subject` or `email`	Include both required fields in payload
No ticket, no error	Hook `wpcf7_mail_sent` not firing	Switch to `wpcf7_before_send_mail`
Ticket created but no requester	Email field not mapped	Confirm `email` key is in the payload

CF7 to Intercom Not Creating Contacts - Four Causes Explained

Rahul Sharma — Mon, 21 Sep 2026 07:43:03 +0000

Intercom is one of the more technically demanding integrations to get right from CF7. The platform has gone through several API authentication changes, deprecated an entire object type (Leads), and has a permission scope system that causes silent failures even with valid tokens.

Here are the four causes that produce the same symptom - form submits, nothing appears in Intercom.

Cause 1: App ID + API Key Authentication Is No Longer Supported

Intercom's older API accepted Basic authentication using an App ID and API Key combination:

Authorization: Basic base64(APP_ID:API_KEY)

A GitHub issue on the intercom-php library documented this exactly: a developer was getting 401 errors using new IntercomClient(APP_ID, API_KEY) even with valid credentials. The fix was switching to the Personal Access Token approach:

Authorization: Bearer YOUR_ACCESS_TOKEN

The App ID + API Key pattern has been deprecated. Modern Intercom API calls require a Personal Access Token or an OAuth App token, both sent as Bearer tokens. If your CF7 to Intercom plugin was built several years ago and uses Basic auth with an App ID and API Key, it will return 401 on every call regardless of whether the credentials are valid.

Generate an Access Token: In Intercom, go to Settings, then Integrations, then Developer Hub. Create a new app or open an existing one. Under Authentication, generate an Access Token. Use this as the Bearer token in every API call.

Cause 2: Token Does Not Have the Required Permission Scopes

Intercom's Access Tokens have granular permission scopes. An Intercom community thread confirmed this directly: "If you try to use an access token that doesn't have the right permissions to query a specific API endpoint, a token_unauthorized error will be returned."

For creating contacts from a CF7 form, your token needs at minimum:

contacts:write — to create and update contact records
contacts:read — to search for existing contacts before creating duplicates

If your token was created with read-only scopes or limited permissions, the API call authenticates successfully but returns token_unauthorized when attempting to write a contact. This looks identical to an invalid token error from the WordPress side.

Check your token's scopes: In the Intercom Developer Hub, open your app, go to Authentication, and review the permissions assigned to your access token. If contacts:write is not included, edit the token permissions to add it.

Cause 3: Intercom Removed the Leads API — Contacts Only Now

This is the cause that breaks older integrations without any obvious error.

Intercom previously had two separate object types for people: Leads (anonymous visitors) and Users (identified contacts). Many early CF7 to Intercom integration plugins were built against the Leads API endpoint:

POST https://api.intercom.io/leads

Intercom merged Leads and Users into a single Contacts object in 2018-2019 and deprecated the Leads endpoint. The current endpoint for all contact creation is:

POST https://api.intercom.io/contacts

A plugin that is still calling the old /leads endpoint will get a 404 or a deprecated endpoint error. The contact is never created. The plugin may log nothing useful because it does not know how to handle the deprecated endpoint response.

Check your plugin: If your CF7 to Intercom plugin was last updated before 2020, it is almost certainly using the old Leads API. Update the plugin or switch to a direct integration using the current Contacts endpoint.

Cause 4: Creating an Archived Contact Returns an Error

An Intercom community thread documented a specific failure when a contact's email already exists in Intercom but the contact was archived: the create endpoint returns an error saying "An archived contact with this email address already exists" rather than creating a new contact or updating the existing one.

This happens when:

A contact previously submitted your form and was archived in Intercom
The same person submits again
The plugin tries to create a new contact
Intercom returns an error because the archived contact blocks creation

The correct handling is to first search for the contact by email, unarchive if found as archived, then update rather than create. Most simple CF7 to Intercom integrations do not handle this edge case.

Workaround: Use Intercom's upsert-style endpoint which handles this automatically, or search before creating.

The Correct CF7 to Intercom Integration

Intercom's current API for creating a contact:

POST https://api.intercom.io/contacts
Authorization: Bearer YOUR_ACCESS_TOKEN
Intercom-Version: 2.11
Content-Type: application/json

{
  "role": "lead",
  "email": "jane@example.com",
  "name": "Jane Smith",
  "phone": "+11234567890",
  "custom_attributes": {
    "message": "Their enquiry message here"
  }
}

The role field accepts "lead" (anonymous, no login) or "user" (identified, has logged in to your product). For CF7 contact forms, "lead" is almost always correct.

The Intercom-Version header is required. Use the current version (2.11 at the time of writing) to ensure predictable API behaviour.

Contact Form to API handles this call from the WordPress dashboard. You set the Intercom contacts endpoint, add your Bearer token, include the Intercom-Version header, and map your CF7 fields to the contact payload. Every submission logs the Intercom response, so you see whether the contact was created or what error was returned.

Quick Diagnosis

Error	Cause	Fix
`401 token_not_found`	Using App ID + API Key instead of Bearer token	Generate Access Token, use as Bearer
`401 token_unauthorized`	Token missing `contacts:write` scope	Add write permission in Developer Hub
`404` on the endpoint	Plugin calling deprecated `/leads` endpoint	Update plugin to use `/contacts`
`"archived contact exists"` error	Email matches an archived Intercom contact	Search first, unarchive, then update
`403` from AWS WAF	Server IP blocked by Intercom's WAF	Contact Intercom support with request IDs

CF7 to ConvertKit (Kit) Not Tagging Subscribers - Four Causes Explained

Rahul Sharma — Fri, 18 Sep 2026 09:37:26 +0000

ConvertKit rebranded to Kit in 2024 and migrated their API from v3 to v4. They also changed from API Key + Secret authentication to OAuth 2.0. These changes, combined with the longstanding confusion between tag names and tag IDs, explain almost every CF7 to ConvertKit/Kit integration failure.

This post covers each cause with the exact technical detail needed to fix it.

Cause 1: API Key vs Secret Key Confusion

A WordPress forum user reported that their plugin showed the ConvertKit connection as validated but no forms were visible in the mapping screen. After back and forth, the resolution was simple: the client had given them the API key instead of the API secret.

ConvertKit's legacy v3 API used two separate credentials:

API Key: Used for some read operations
API Secret: Required for subscriber creation and tagging

Most CF7 integration plugins that use ConvertKit's v3 API require the API Secret, not the API Key. These two values are shown in the same settings page in ConvertKit under Advanced > API but they look different and have different lengths. Entering the API Key where the Secret is expected causes the connection to validate (it is a valid credential format) but subscriber operations fail silently.

Check: In ConvertKit (now Kit), go to Settings, then Advanced, then scroll to the API section. Confirm which credential your CF7 plugin is asking for and enter the matching one.

Cause 2: ConvertKit Rebranded to Kit — Old API Endpoints Are Changing

In 2024, ConvertKit officially rebranded to Kit and began migrating their API from v3 to v4. The v4 API uses OAuth 2.0 instead of API Key/Secret. Plugins that were built against the v3 API need to be updated to work with v4.

What this means for CF7 integrations:

Plugins using the old api.convertkit.com/v3/ base URL may stop working as Kit deprecates v3 endpoints
The new v4 API is at api.kit.com/v4/ with a completely different authentication flow
The tag application and subscriber creation payloads have changed between v3 and v4

If your CF7 to ConvertKit plugin was last updated before 2024, it may be running against deprecated v3 endpoints with an authentication pattern that is being phased out.

Check your plugin's last updated date. If it has not been updated since 2023, check the plugin changelog or support forum for v4/Kit migration notes.

Cause 3: Tag Name vs Tag ID Confusion

This is the most common cause of tags not being applied even when the subscriber is added correctly.

ConvertKit's v3 API applies tags using the tag's numeric ID, not its name. The tag named "Website Enquiry" has an ID like 4567890. If your integration is sending the tag name instead of the tag ID, ConvertKit accepts the subscriber but ignores the tag.

This is a confusing failure because some plugin UIs show tag names in a dropdown (they look up the IDs behind the scenes) while others require you to manually enter the tag ID. If your plugin asks for a "tag" and shows you a text field rather than a populated dropdown, it probably wants the numeric ID.

Find your tag IDs:

# ConvertKit v3
curl "https://api.convertkit.com/v3/tags?api_secret=YOUR_API_SECRET"

# Kit v4
curl "https://api.kit.com/v4/tags" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Each tag object in the response has an id field. That number is what goes in your tag configuration.

Apply a tag to a subscriber (v3):

POST https://api.convertkit.com/v3/tags/{TAG_ID}/subscribe
api_secret: YOUR_SECRET

{
  "api_secret": "YOUR_SECRET",
  "email": "subscriber@example.com"
}

Tag a subscriber (v4):

POST https://api.kit.com/v4/subscribers/{subscriber_id}/tags
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json

{
  "tag_ids": [TAG_ID_1, TAG_ID_2]
}

Note: in v4, tagging requires the subscriber's ID, which means you must first create the subscriber and capture their ID from the response before you can apply tags. This is a two-step flow.

Cause 4: ConvertKit Forms vs Tags — Different Subscription Mechanisms

ConvertKit has two ways to subscribe someone: through a Form or through a Tag. These behave differently.

Subscribing via a Form: Uses the form's specific subscribe endpoint. Triggers the form's opt-in confirmation email if double opt-in is enabled. Places the subscriber in the form's subscriber list.

Subscribing with a Tag: Adds a tag to an existing or new subscriber. Does not send an opt-in confirmation unless you have an automation set up to trigger one.

Many CF7 to ConvertKit integrations only support Form-based subscription. If you configure one of these integrations expecting tags to be applied, you will find subscribers are added to the form's list but no tags appear.

If you need tags applied at subscription time, you need a plugin or direct API implementation that specifically supports the tag subscription endpoint, not just the form subscription endpoint.

Direct API Integration With Contact Form to API

Contact Form to API gives you direct control over which ConvertKit/Kit endpoint receives your data and what the payload looks like.

For a two-step ConvertKit v3 flow (create subscriber then apply tag):

Step 1 — Subscribe:

POST https://api.convertkit.com/v3/forms/{FORM_ID}/subscribe
Content-Type: application/json

{
  "api_key": "YOUR_API_KEY",
  "email": "[your-email]",
  "first_name": "[your-name]"
}

Step 2 — Apply tag (use the subscriber_id from Step 1 response):

POST https://api.convertkit.com/v3/tags/{TAG_ID}/subscribe
Content-Type: application/json

{
  "api_secret": "YOUR_SECRET",
  "email": "[your-email]"
}

The Pro version's chained API call feature passes the subscriber ID from Step 1's response into Step 2's payload automatically.

Quick Diagnosis

Symptom	Most Likely Cause
Connection validated but no forms in dropdown	API Key used instead of API Secret
Subscribers added but no tags applied	Tag name sent instead of Tag ID
Integration stopped working after Kit rebrand	Plugin using deprecated v3 endpoints
Double opt-in confirmation sent when using tag subscription	Wrong endpoint — using form subscribe instead of tag subscribe
Tags applied but automations not triggering	Tag ID correct but automation trigger not set up in Kit

CF7 to MailerLite Not Adding Subscribers to the Right Group - Four Causes

Rahul Sharma — Thu, 17 Sep 2026 10:12:04 +0000

Multiple WordPress support threads document the same frustrating pattern with CF7 to MailerLite integrations. Subscribers either do not appear at all, or they land in the general subscribers list instead of the specific group selected in the plugin settings. No error is shown on the form. The submission appears to succeed.

Four distinct causes produce this identical symptom. Here is each one with exactly what to check.

Cause 1: Double Opt-In Is Enabled on the Group

This was the resolution in two separate forum threads. One was closed with just this note: "The issue was solved through email. Double opt-in option was on."

When double opt-in is enabled on a MailerLite group, subscribers added via API are placed in a pending state until they confirm their email. They do not appear in the group as active subscribers. From the WordPress side, the integration looks like it did nothing — the person is not in the group.

The person was added. They are pending. They just do not appear as active subscribers until they click the confirmation email.

Check this first: In your MailerLite account, go to Subscribers, then Groups. Open the group your CF7 integration is adding to. Click Settings. Look for the double opt-in setting. If it is enabled and you want subscribers added immediately without a confirmation step, disable it.

Alternatively, if you need double opt-in for GDPR compliance, understand that this is working correctly — the subscriber will appear in the group after they confirm. Set up MailerLite to send the confirmation email correctly and check the Unconfirmed tab in the group to see pending subscribers.

Cause 2: Classic API Key vs New API Key

MailerLite migrated their API in 2022-2023 from a "Classic" version to a "New" version. These are not interchangeable. Classic API keys (generated in the old MailerLite dashboard) do not work with New API endpoints, and vice versa.

A forum user reported that data was getting through to MailerLite but the subscriber was not being added to the group. The plugin was using the MailerLite Classic API SDK while their MailerLite account was on the New platform.

How to tell which you have:

If your MailerLite account URL is app.mailerlite.com — you are on the New platform. You need a New API key.
If your account URL is app.mailerlite.com/classic or you signed up before 2022 and have not migrated — you may still be on Classic.

Generate the correct API key:

New MailerLite: go to Integrations, then API, then create a token
Classic MailerLite: go to Integrations, then Developer API

If the plugin you are using was last updated before 2023, it is likely using the Classic API SDK and will not work correctly with a New API key.

Cause 3: CleanTalk or Spam Plugin Conflicting With the Submission Hook

One forum thread documented a specific CleanTalk interaction. The site owner was using Contact Form 7 Connector for MailerLite sign-ups. With CleanTalk enabled, every submission returned "There was an error trying to send your message" and no subscriber was added. Disabling CleanTalk fixed it immediately.

The CleanTalk dashboard showed all events as "approved" — no spam detected. But something in CleanTalk's processing was interfering with the CF7 hook execution before the MailerLite integration could fire.

If you are using CleanTalk:

Temporarily disable CleanTalk and test the form
If subscribers are added correctly without CleanTalk, the conflict is confirmed
In CleanTalk settings, look for a "Forms to Protect" whitelist and add your CF7 form
Also check "Protect Logged-in Users" — disable it if you are testing while logged in

The same conflict can occur with other aggressive spam protection plugins (Cerber Security, WP Cerber) that intercept form submissions before CF7's hooks complete.

Cause 4: Plugin Not Updated for MailerLite's API Migration

A forum user trying the CF7 Connector MailerLite add-on reported subscribers were not being added to the correct group. A community member confirmed: "Looks like the plugin wasn't updated to be compatible with the latest version of MailerLite." The user switched to AFI (Advanced Form Integration) and it worked immediately with the same API key and group settings.

This is the structural problem with dedicated integration plugins that depend on a specific email platform's API: when the platform migrates their API, the plugin must be updated to match. If the plugin author is slow to update or has abandoned the plugin, users are left with an integration that authenticates successfully but fails silently on group assignment.

Check: Look at the plugin's last updated date in WordPress admin and compare it to MailerLite's API migration announcement (2022-2023). If the plugin predates the migration and has not been updated since, it is running against a deprecated API.

Calling MailerLite's New API Directly

The MailerLite New API endpoint for adding a subscriber to a group:

POST https://connect.mailerlite.com/api/subscribers
Authorization: Bearer YOUR_NEW_API_TOKEN
Content-Type: application/json
Accept: application/json

{
  "email": "jane@example.com",
  "fields": {
    "name": "Jane Smith",
    "last_name": ""
  },
  "groups": ["GROUP_ID_HERE"],
  "status": "active"
}

Get your group IDs:

curl "https://connect.mailerlite.com/api/groups" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Accept: application/json"

The id field in each group object is what goes in the groups array.

Contact Form to API calls this endpoint directly from the WordPress dashboard. You configure the MailerLite New API endpoint, add your token as a Bearer header, and map your CF7 fields to the subscriber payload. The group ID goes directly in the groups array in your JSON body — no plugin middleware that might be running against the old Classic API.

Quick Diagnosis

Symptom	Most Likely Cause
Subscriber appears in Unconfirmed tab	Double opt-in enabled on the group
Subscriber in all subscribers but not in group	Double opt-in enabled OR group ID wrong
No subscriber created, no error	CleanTalk or spam plugin conflict
Subscriber not added, error in debug log	Classic API key with New platform (or vice versa)
Was working, stopped after MailerLite update	Plugin not updated for API migration

Stop Paying Zapier to Connect Your CF7 Form to a CRM

Rahul Sharma — Wed, 16 Sep 2026 09:53:54 +0000

Zapier is the default answer when someone asks how to connect Contact Form 7 to a CRM. It shows up in every search result. It is easy to set up. It works.

It is also significantly more expensive than the alternative and for a simple CF7-to-CRM connection, the alternative does exactly the same job without the per-task pricing.

This post breaks down the cost comparison, explains where Zapier adds genuine value versus where it is overkill, and shows you how to replace it with a direct API integration for the common CF7 use case.

The Zapier Cost Model for CF7 Integrations

Zapier charges per task. One task = one action in one Zap triggered once. If your CF7 form submission triggers two actions (create a CRM contact and add to a Mailchimp list), that is two tasks per submission.

At 500 form submissions per month going to two destinations:

500 submissions × 2 actions = 1,000 tasks/month

Zapier's Starter plan: $19.99/month for 750 tasks. You are already over the limit.
Zapier's Professional plan: $49.99/month for 2,000 tasks.

At 1,000 submissions/month to two destinations (2,000 tasks):

Professional plan: $49.99/month = $599.88/year

For a setup that could be replaced by a one-time plugin licence.

What the Direct Alternative Costs

Contact Form to API handles CF7-to-API connections directly from WordPress. The free plan covers up to 5 API connections per form. The Pro licence is a one-time payment.

At 1,000 submissions/month to two destinations:

Contact Form to API: one-time licence cost
Zapier Professional: $49.99/month recurring

The plugin pays for itself in the first month or two.

Where Zapier Is Worth Paying For

Before replacing Zapier entirely, be honest about what you are using it for. Zapier earns its cost in specific situations:

Complex conditional routing: If different form responses should go to different CRMs or different pipeline stages based on what the user selected, Zapier's visual workflow builder handles branching logic well. A direct plugin handles fixed destinations - all submissions go to the same endpoints. Conditional routing based on field values requires the Pro version's conditional logic features or a workflow platform.

Non-API destinations: Zapier connects to 5,000+ apps, many of which do not expose a REST API. If you need CF7 submissions to update a Google Calendar event, create a Notion page through Notion's proprietary sync, or trigger a specific action in a tool without a proper REST API, Zapier is the correct tool.

Multi-app workflows with delays: If your workflow needs to wait 24 hours then send a follow-up email, check a condition, then update a CRM field - Zapier's scheduler handles time-based workflow logic. A direct plugin does not.

For everything else a form that sends data to a CRM and optionally an email list a direct plugin removes the per-task cost entirely.

The GDPR Consideration

When a CF7 submission passes through Zapier, the data (name, email, enquiry content) is processed on Zapier's servers before reaching your CRM. For sites serving EU users under GDPR:

Zapier must be listed as a data processor in your privacy notice
A Data Processing Agreement (DPA) must be in place with Zapier
Zapier's data handling practices become part of your compliance posture

A self-hosted WordPress plugin processes submissions entirely within your server. No third-party server receives the data in transit. For legal firms, healthcare providers, or any operator with privacy-conscious clients, this is a structural advantage that the monthly cost comparison does not capture.

The Three-Point Failure Model vs One-Point

A Zapier-based CF7 integration has three potential failure points:

CF7 webhook delivery from WordPress to Zapier
Zapier's internal processing and task execution
Zapier's delivery to the destination API

If any of the three fails, the lead is lost. Zapier's task history log will show the failure — but only if you are watching it.

A direct plugin integration has one potential failure point: the WordPress server's outbound HTTP call to the destination API. If it fails, it fails at one place, with one log entry, on your own server.

The Setup: CF7 to HubSpot Directly

Here is what the direct integration looks like for the most common use case — CF7 to HubSpot — using Contact Form to API:

Endpoint:   https://api.hubapi.com/crm/v3/objects/contacts
Method:     POST
Headers:    Authorization: Bearer YOUR_PRIVATE_APP_TOKEN
            Content-Type: application/json

Body:
{
  "properties": {
    "email":       "[your-email]",
    "firstname":   "[your-name]",
    "phone":       "[your-phone]",
    "hs_lead_status": "NEW",
    "lifecyclestage": "lead"
  }
}

CF7 field names in brackets are replaced with submitted values before the request fires. No Zapier account. No webhook. No task counter. Just a direct POST from your WordPress server to HubSpot's API.

Add a second connection for Mailchimp and both fire simultaneously on every submission. Still no Zapier.

When to Keep Zapier

Keep Zapier if:

You need conditional routing based on form field values (send enterprise leads to one CRM, SMB leads to another)
You need to connect to tools that have no REST API
You need time-delayed workflows (follow up 3 days after submission)
You are already paying for Zapier for other non-CF7 automations and have spare tasks

Replace Zapier if:

You are using it only to relay CF7 submissions to one or two API destinations
The per-task cost is scaling with your form volume
You want data to stay within your own WordPress server for GDPR reasons
You want fewer external dependencies in your lead capture stack