DEV Community: Rahul Sharma

Your Contact Form Isn't the Problem-Your Integration Might Be

Rahul Sharma — Wed, 29 Jul 2026 10:51:58 +0000

As developers, we've all received some version of this support request:

"A customer says they submitted the contact form, but nothing showed up in our CRM."

The instinctive response is usually to investigate Contact Form 7, SMTP logs, or the mail server. Those are valid places to start, but they often distract us from a more important question:

Did the form submission actually make it to the CRM?

I recently came across a discussion in the Agile CRM community where a user mentioned that they were no longer receiving notifications when someone filled out a form. They also reported other concerns with the platform, but the notification issue stood out because it's something many developers have encountered in different CRMs not just Agile CRM.

Whether the root cause is the CRM, email delivery, or configuration, the lesson is the same: notification emails should never be treated as proof that your integration is working.

The common misconception

Many businesses think this is their lead capture workflow:

Visitor
   ↓
Contact Form 7
   ↓
Notification Email
   ↓
Sales Team

In reality, the notification email is only a side effect of a much larger process.

The actual workflow is closer to this:

Visitor
   ↓
Contact Form 7
   ↓
API Integration
   ↓
CRM
   ↓
Automation
   ↓
Notification

If the notification never arrives, it doesn't automatically tell you where the failure occurred.

Was the form submitted successfully?

Did WordPress process the request?

Was the API request sent?

Did the CRM reject the payload?

Or did the CRM create the lead successfully while the notification workflow failed?

Without tracing the complete flow, you're only guessing.

Make the CRM the source of truth

A better architecture is to stop treating email notifications as the primary signal that a lead exists.

Instead, the CRM should become the source of truth.

After a form submission, your first validation should be:

Did the API request leave WordPress?
Did the CRM return a successful response?
Was the contact or lead created?

If those three steps succeed, you've already achieved the primary objective.

Whether an email notification is triggered afterwards becomes a separate concern.

This separation makes debugging much simpler because you're validating the system that actually stores your lead data.

Why API integrations are more predictable

One of the biggest advantages of API-based integrations is visibility.

Instead of hoping that different systems communicate correctly behind the scenes, developers can inspect each request and response.

That gives you the ability to verify:

request payloads
authentication headers
response codes
field mappings
validation errors
rate-limit responses

This makes troubleshooting repeatable instead of relying on assumptions.

For example, if a CRM returns a validation error because a required field is missing, you'll know immediately why the lead wasn't created.

That's much more useful than simply noticing that nobody received an email.

Don't replace Contact Form 7

When clients experience integration problems, they often ask whether they should switch form plugins altogether.

In most cases, the answer is no.

Contact Form 7 is already responsible for collecting user input effectively.

The real challenge is ensuring that data reaches external systems reliably.

That means improving the integration layer rather than rebuilding the forms users already know.

Connecting Contact Form 7 directly to Agile CRM

If your website uses Contact Form 7, a cleaner approach is to send submissions directly to Agile CRM through its API.

The architecture becomes much easier to understand:

Contact Form 7
        ↓
HTTP Request
        ↓
Agile CRM API
        ↓
Lead Created

Instead of depending on notification workflows, the CRM receives structured data directly from the website.

As developers, that's generally the workflow we want because every stage can be tested independently.

Where Contact Form to API fits

This is where Contact Form to API becomes useful.

Rather than replacing Contact Form 7, it allows developers to configure API requests that send form submissions directly to external platforms like Agile CRM.

Because the integration happens through APIs, you have greater control over:

HTTP methods
authentication
custom headers
JSON payload mapping
request endpoints
field transformations

If you're implementing this workflow, these resources are worth reading:

How to Integrate Contact Form 7 with Agile CRM Using API
https://www.contactformtoapi.com/how-to-integrate-contact-form-7-with-agile-crm-using-api/
Contact Form 7 CRM Integration Guide
https://www.contactformtoapi.com/contact-form-7-crm-integration/

A simple debugging checklist

Whenever a client reports missing leads, I try to answer these questions in order:

Did Contact Form 7 receive the submission?
Was the API request triggered?
Did the request reach the CRM endpoint?
Was authentication successful?
Did the CRM return a success response?
Was the lead actually created?

Notice what's missing from that list.

Email notifications.

They're useful, but they're not where I begin debugging.

Final thoughts

The Agile CRM community discussion is a good reminder that every integration should be designed with reliability in mind.

If your lead capture workflow depends entirely on notification emails, you'll eventually spend time chasing symptoms instead of understanding the actual flow of data.

A direct API integration provides something developers value far more than notifications:

Visibility.

When every request, response, and payload can be inspected, diagnosing issues becomes significantly easier.

If you're already using Contact Form 7, improving the integration layer is often a better investment than replacing the forms themselves.

How do you debug CRM integrations when clients report missing leads? I'd be interested to hear what your workflow looks like.

When a WordPress-to-CRM Integration Works Sometimes: A Practical Guide to Debugging Intermittent Failures

Rahul Sharma — Thu, 23 Jul 2026 08:27:04 +0000

One of the worst integration bugs is not an error that happens every time.

It is an error that happens only sometimes.

The workflow looks like this:

Submission 1 → Success
Submission 2 → Success
Submission 3 → Failure
Submission 4 → Success
Submission 5 → Failure

The website is still online.

The form is still visible.

Some leads reach the CRM.

Others do not.

Now the real debugging question is not:

“Why is the integration broken?”

It is:

“What was different about the submissions that failed?”

That question is much more difficult to answer.

The reliability problem behind intermittent integrations

A review of the Insightly CRM integration in the Xero App Store described an experience where the integration worked initially, stopped working, appeared to work inconsistently, worked again, and later failed again.

The specific experience belongs to the reviewer, so it should not be treated as a universal statement about every Insightly integration.

However, the technical problem is familiar:

An integration that works inconsistently is difficult to trust.

For a website form, this can become a serious issue.

A visitor submits an inquiry.

The website displays a success message.

But the CRM record may not exist.

From the visitor's perspective:

Form submitted
      ↓
Success message

From the business's perspective:

Form submitted
      ↓
?
      ↓
CRM record

That gap is where important data can disappear.

A form submission is not a single event

A typical WordPress form-to-CRM workflow contains multiple stages:

Browser
   ↓
WordPress
   ↓
Contact Form 7
   ↓
Integration
   ↓
HTTP Request
   ↓
CRM API
   ↓
CRM Processing
   ↓
Contact Record

A successful form submission only confirms that the first part of the process completed.

It does not prove that the CRM accepted the data.

This distinction is important when debugging.

Consider:

Form Success
      ↓
API Request Failed

The visitor may still see:

Thank you, your message has been sent.

But the CRM never receives the lead.

This is why the first debugging rule should be:

Do not treat form success and CRM success as the same event.

Start with a specific failed submission

When an integration behaves inconsistently, avoid starting with random test submissions.

Choose one specific submission that should have created a CRM record.

For example:

Submission:
Email: customer@example.com
Time: 14:32
Form: Project Inquiry

Then trace the request:

1. Was the form submission received?
          ↓
2. Was the integration triggered?
          ↓
3. Was an HTTP request sent?
          ↓
4. What response was returned?
          ↓
5. Was the CRM record created?

This gives you a concrete debugging path.

Instead of saying:

“The integration sometimes fails.”

You can begin asking:

“Where did this particular submission stop?”

That is a much more useful question.

Step 1: Verify the form submission

Before checking the CRM API, verify that the form submission actually reached WordPress.

The first stage is:

Browser
   ↓
Contact Form 7

Potential problems at this stage can include:

client-side validation
server-side validation
missing required values
spam protection
JavaScript errors
server-side errors

If the submission never reached the form-processing stage, the CRM integration is not the cause.

The debugging path stops here:

Browser
   ↓
WordPress
   ✗

The important lesson is to troubleshoot the workflow in order.

Do not jump directly to the final system.

Step 2: Verify that the integration was triggered

If the form submission was received, the next question is:

Did the integration actually run?

The expected flow is:

Contact Form 7
      ↓
Integration Trigger
      ↓
API Request

An intermittent problem could look like this:

Submission A → Triggered
Submission B → Triggered
Submission C → Not Triggered

In this situation, the API itself may be working correctly.

The problem is that the request was never sent.

This is a completely different problem from:

Request Sent
      ↓
API Rejected

Separating these two cases can save a lot of debugging time.

Step 3: Verify that an HTTP request was sent

Once the integration trigger is confirmed, check whether the outbound request was actually made.

The workflow should look like:

Form Submission
      ↓
Integration
      ↓
HTTP Request
      ↓
CRM API

Now there are two different scenarios.

Scenario A: No request was sent

Form
  ✓
  ↓
Integration
  ✓
  ↓
HTTP Request
  ✗

The problem may be in:

integration configuration
conditional logic
request setup
execution errors

Scenario B: The request was sent

Form
  ✓
  ↓
Integration
  ✓
  ↓
HTTP Request
  ✓
  ↓
CRM API

Now the response needs to be investigated.

The difference between these two situations is critical.

A request that was never sent cannot be fixed by changing the CRM payload.

Step 4: Inspect the response

If the request was sent, inspect the response.

The response can provide important information about what happened.

For example:

200 OK

may indicate a successful request.

While:

400 Bad Request

may indicate a problem with the data.

And:

401 Unauthorized

may indicate an authentication problem.

Other possible issues include:

incorrect endpoint
invalid credentials
missing required fields
invalid request body
permissions
rate limits
timeouts

The response is more useful than simply knowing that the CRM record is missing.

It helps identify where the failure occurred.

Compare successful and failed requests

When the problem is intermittent, compare a successful request with a failed request.

For example:

Successful request

{
  "name": "Alice",
  "email": "alice@example.com",
  "company": "Example Inc."
}

Failed request

{
  "name": "Bob",
  "email": "bob@example.com",
  "company": ""
}

The integration may appear random.

But the actual problem may be the missing company value.

This is why the following question is useful:

What changed between the successful and failed requests?

Compare:

field values
field names
request headers
authentication
endpoint
request timing
payload structure

Intermittent problems often become easier to understand when the requests are compared directly.

Field mapping is a common source of data problems

The form field names and CRM field names may be different.

For example, Contact Form 7 might use:

your-name
your-email
company

The API may expect:

name
email
company_name

The mapping needs to be clear:

your-name  → name
your-email → email
company    → company_name

A mapping problem may not affect every submission.

For example:

Company value exists
      ↓
Request accepted

But:

Company value missing
      ↓
Request rejected

The result may look like an unreliable integration even though the failure is caused by a specific data condition.

Authentication should also be tested separately

A request can fail because of authentication.

Depending on the API, the request may use:

API keys
bearer tokens
OAuth
basic authentication
custom headers

A typical workflow may look like:

Valid Credentials
      ↓
Request Accepted

Later:

Expired or Invalid Credentials
      ↓
Request Rejected

If the credentials are updated and the integration begins working again, the problem may appear intermittent.

For this reason, authentication should be checked whenever an integration suddenly stops working.

Not every failure is a configuration problem

Sometimes the request is correctly configured but the receiving service temporarily fails.

For example:

WordPress
   ↓
API Request
   ↓
Timeout

This is different from:

WordPress
   ↓
API Request
   ↓
Invalid Authentication

And different again from:

WordPress
   ↓
API Request
   ↓
Invalid Payload

Each failure requires a different response.

A timeout may require retry logic or temporary investigation.

An authentication error requires credential verification.

An invalid payload requires checking the request data.

The response should determine the next debugging step.

Keep the form and API connection separate

A WordPress website does not necessarily need to replace its existing Contact Form 7 forms to connect with an external CRM.

A simpler architecture can be:

Contact Form 7
      ↓
API Connection
      ↓
Insightly CRM

The form handles the visitor-facing experience.

The API connection handles the data transfer.

The CRM handles the contact and lead management.

This separation allows the existing form to remain in place while the connection to the external system is configured separately.

For WordPress websites that need to send Contact Form 7 submissions to external APIs, Contact Form to API provides a way to create that connection.

The key point is not that an API connection eliminates every possible failure.

The key point is that the data path can be configured and investigated as a distinct part of the workflow.

Build a failure-focused test plan

A single successful test is not enough to establish reliability.

Test different conditions.

Normal submission

Valid Data
      ↓
Expected Success

Missing required value

Required Field Missing
      ↓
Expected Validation Error

Invalid data

Invalid Value
      ↓
Expected API Error

Repeated submission

Same Contact
      ↓
Expected Duplicate Behavior

Authentication failure

Invalid Credentials
      ↓
Expected Authentication Error

Temporary service failure

Unavailable API
      ↓
Expected Failure Handling

The purpose of testing is not only to confirm that the integration works.

It is to understand how the integration behaves when it does not work.

A practical debugging checklist

When a Contact Form 7 submission does not appear in Insightly CRM, follow this sequence:

1. Was the form submitted?
          ↓
2. Was the integration triggered?
          ↓
3. Was the request sent?
          ↓
4. Was authentication valid?
          ↓
5. Was the endpoint correct?
          ↓
6. Was the payload valid?
          ↓
7. What response was returned?
          ↓
8. Was the CRM record created?

This order matters.

If the request was never sent, there is no reason to start debugging the CRM response.

If the request was rejected with a 401, checking the form field names is probably not the first step.

If the request returned a validation error, authentication may not be the problem.

Start where the failure actually occurred.

The goal is traceability

The most useful question for an intermittent integration is:

“What happened to this specific form submission?”

The complete workflow should be understandable:

Form Submission
      ↓
Integration Trigger
      ↓
HTTP Request
      ↓
Authentication
      ↓
Payload
      ↓
API Response
      ↓
CRM Record

If one stage fails, the workflow should provide enough information to identify that stage.

Without that visibility, the business may only discover a problem after a lead is missing.

By then, it may be too late.

Final thoughts

A CRM integration that works once has only passed one test.

A CRM integration that works consistently needs to be tested under different conditions.

When a WordPress-to-CRM workflow works, stops, starts working again, and fails later, the correct response is not to guess.

Trace the request.

Start with the form.

Check the trigger.

Verify the HTTP request.

Inspect the response.

Compare successful and failed submissions.

Then verify the CRM record.

The goal is not simply:

Form → CRM

The goal is to understand the complete path:

Form
 ↓
Trigger
 ↓
Request
 ↓
Response
 ↓
CRM Record

For WordPress websites using Contact Form 7, Contact Form to API can be used to connect form submissions with external APIs.

If you are specifically working on a Contact Form 7 and Insightly CRM connection, see How to Connect Contact Form 7 with Insightly CRM in WordPress.

When an integration behaves inconsistently, the most important thing is not simply making the next submission work.

It is understanding why the previous one failed.

When Native CRM Forms Stop Being Enough: Building Flexible WordPress-to-Agile CRM Workflows

Rahul Sharma — Wed, 22 Jul 2026 12:01:29 +0000

Small businesses usually start with simple requirements.

A website.

A contact form.

A CRM.

A way to follow up with new leads.

The initial workflow might look like this:

```text id="3q7m4f"
Website Form
↓
CRM
↓
Follow-up




For a basic contact form, this may be enough.

The form collects:



```text id="p7j90z"
Name
Email
Message

The submission reaches the CRM.

The sales team follows up.

Simple.

But as the business grows, the website usually becomes more complex.

The business may need:

multiple forms
custom fields
different lead sources
service-specific questions
conditional fields
custom validation
different workflows
integrations with other tools

At this point, the problem is no longer simply:

“How do I collect a lead?”

The problem becomes:

“How do I collect different types of lead data and reliably send it into the correct business workflow?”

This is where native CRM forms can sometimes become limiting for the website.

The CRM may still be valuable.

The challenge is giving the website enough flexibility to collect and process the data the business actually needs.

An API-based connection can act as the bridge between the two systems.

The difference between a CRM form and a website form

A CRM form is generally designed around the CRM's data structure.

A WordPress form is designed around the website visitor's experience.

These are different priorities.

A WordPress website may need:

custom HTML
custom CSS
custom validation
conditional fields
multiple layouts
different form types
custom user experiences

For example, a business might have:

```text id="k9f54w"
Contact Form
↓
General Inquiry






```text id="6ccqka"
Demo Form
      ↓
Sales Workflow

```text id="q8y2j5"
Quote Form
↓
Qualification Workflow






```text id="5b6g7q"
Support Form
      ↓
Support Workflow

Each form may require different fields.

Each form may require different processing.

Trying to force all of these use cases into one basic CRM form can make the system harder to maintain.

A more flexible architecture separates the website form from the CRM:

```text id="3v95wq"
WordPress Form
↓
API Layer
↓
Agile CRM




The WordPress form handles the user experience.

The API handles communication.

Agile CRM manages the contact and lead data.

## The requirements change as a business grows

A business may start with:



```text id="v2q8yw"
Name
Email
Message

Later, the sales team may need:

```text id="m7gq4q"
Name
Email
Phone
Company
Service Required
Budget
Project Timeline
Lead Source
Additional Notes




The form is now collecting much more useful business context.

But this also creates a more complex integration.

The workflow may need to:

1. collect the form data
2. validate the values
3. map the fields
4. build the request payload
5. authenticate the API request
6. send the data
7. handle the response

The form-to-CRM connection has become a data integration.

## Field mapping is where many integrations become difficult

A WordPress form and a CRM do not necessarily use the same field names.

For example, a Contact Form 7 form may contain:



```text id="xw2d4q"
your-name
your-email
your-phone
company
service
budget

The CRM may expect:

```text id="h3nq2z"
name
email
phone
company_name
service_type
budget_range




The integration needs to map the fields:



```text id="z3l5p6"
your-name  → name
your-email → email
your-phone → phone
company    → company_name
service    → service_type
budget     → budget_range

This mapping step is important because the form field name is not automatically the same as the CRM field name.

A request payload might look like:

```json id="p1s3d5"
{
"name": "John Doe",
"email": "john@example.com",
"phone": "+1 555 123 4567",
"company_name": "Example Inc.",
"service_type": "Website Redesign"
}




If the receiving API expects `company_name` but receives `company`, the data may not be stored correctly.

The form may have collected the data successfully.

The problem happens during the transfer.

## Custom fields become more important as lead qualification improves

Basic contact information is often not enough for a sales team.

A business may want to know:



```text id="2o0s7v"
What service are you interested in?
What is your budget?
When do you want to start?
How did you hear about us?
What is your company size?

This information can help the business prioritize leads.

For example:

```text id="r9n2b5"
High Budget
↓
Priority Follow-up






```text id="j6s0t1"
Urgent Timeline
    ↓
Fast Sales Response

```text id="3g0q2m"
Specific Service
↓
Specialized Sales Workflow




But this only works if the custom field data reaches the CRM correctly.

A form field that never reaches the CRM cannot be used effectively for CRM automation.

## Different forms often need different workflows

Consider a business with three WordPress forms.

### General Contact Form



```text id="w0g6xk"
Name
Email
Message

Project Inquiry Form

```text id="p3s8k2"
Name
Email
Company
Project Type
Budget
Timeline




### Consultation Form



```text id="e4m8q9"
Name
Email
Business Type
Main Challenge
Preferred Date

These forms should not necessarily follow the same workflow.

The process might look like:

```text id="g2q6f8"
General Contact
↓
General CRM Workflow






```text id="t5r8y1"
Project Inquiry
      ↓
Sales Qualification Workflow

```text id="m3n7p0"
Consultation Request
↓
Consultation Follow-up Workflow




An API-based connection can allow each form to send the data required by its specific workflow.

The website does not need to use one identical form structure for every type of visitor.

## Why an API layer provides more flexibility

Without an API layer, the website may be tightly coupled to the CRM form system.

The architecture may look like:



```text id="k4r8x1"
CRM Form
      ↓
CRM

With an API-based connection:

```text id="q5v2m8"
WordPress Form
↓
Field Mapping
↓
API Request
↓
Agile CRM




This gives the website more freedom.

The website can:

* change the form design
* add new fields
* create new forms
* collect different information
* connect to multiple systems

The CRM can continue managing:

* contacts
* leads
* follow-up
* sales workflows

The API connection acts as the communication layer between them.

## API requests require more than a URL

A reliable API integration needs the correct configuration.

This can include:

* endpoint
* HTTP method
* authentication
* headers
* request body
* field mapping
* required fields

For example:



```http id="6k8z3n"
POST /contacts
Authorization: Bearer YOUR_TOKEN
Content-Type: application/json

With a payload:

```json id="5t7x2r"
{
"name": "John Doe",
"email": "john@example.com"
}




If the endpoint is incorrect:



```text id="9b1c4a"
404 Not Found

If authentication is invalid:

```text id="2x6m8q"
401 Unauthorized




If the payload is invalid:



```text id="7p3v9k"
400 Bad Request

This is why API-based form automation should be configured and tested carefully.

Validation needs to work across both systems

The website form may have its own validation rules.

The CRM may have different requirements.

For example:

```text id="f4m8q2"
WordPress:
email = optional

CRM:
email = required




The visitor can successfully submit the WordPress form.

The CRM can reject the API request.

This creates a mismatch between the two systems.

A reliable integration needs to consider both sides:



```text id="n8w3p6"
WordPress Validation
        ↓
API Request
        ↓
CRM Validation

The fields required by the CRM should be collected and validated by the form whenever possible.

The API response is part of the workflow

Sending an API request is not the end of the process.

The response also matters.

A simplified workflow looks like this:

```text id="c2m7v9"
Form Submission
↓
API Request
↓
API Response
↓
Success or Error




A successful response may indicate that the contact was created.

An error response may indicate:

* invalid authentication
* incorrect endpoint
* missing required field
* invalid payload
* insufficient permissions

Without checking the response, debugging becomes guesswork.

The form may appear to work while the API request is failing in the background.

## The CRM may be only one part of the workflow

As businesses grow, the form submission may need to reach more than one system.

For example:



```text id="r4p7w2"
WordPress Form
      ↓
Agile CRM
      ↓
Email Automation

Or:

```text id="m8q2v6"
WordPress Form
↓
Agile CRM
↓
Internal Notification




Or:



```text id="z6n3k8"
WordPress Form
      ↓
CRM
      ↓
Project Management Tool

The website form can become the starting point for a larger business workflow.

An API-based architecture makes it easier to connect the form submission to external systems.

You may not need to replace your existing Contact Form 7 forms

Many WordPress websites already use Contact Form 7.

The existing forms may already include:

custom styling
validation
required fields
spam protection
custom messages
an established user experience

Replacing the form simply to connect it to a CRM can create unnecessary work.

A connection layer can allow the existing form to remain in place:

```text id="b6r2x9"
Existing Contact Form 7
↓
API Connection
↓
Agile CRM




The website continues to control the form experience.

The CRM continues to manage the lead data.

For WordPress websites using Contact Form 7, [Contact Form to API](https://www.contactformtoapi.com/) can help connect existing form submissions with external APIs and business systems.

This approach can be useful when the business wants more flexibility without rebuilding its existing website forms.

## A practical example

Imagine a small agency using Agile CRM.

The agency has three website forms.

### Contact Form



```text id="f3q7m1"
Name
Email
Message

Project Inquiry Form

```text id="h5k8p2"
Name
Email
Company
Project Type
Budget
Timeline




### Consultation Form



```text id="v1n6r4"
Name
Email
Business Type
Main Challenge
Preferred Date

The workflows could look like:

```text id="t8y2m5"
Contact Form
↓
API Request
↓
General CRM Workflow






```text id="q4w7k9"
Project Inquiry
      ↓
API Request
      ↓
Sales Qualification Workflow

```text id="c6p1s3"
Consultation Form
↓
API Request
↓
Consultation Workflow




Each form remains optimized for its specific purpose.

The API connection transfers the data.

Agile CRM remains the central place for managing the contacts and leads.

## When should a business consider API-based form automation?

There is no single point at which every business needs an API integration.

However, these are common signs that a basic form workflow may no longer be enough:

* the website has multiple forms
* each form collects different fields
* custom CRM fields are important
* manual data entry is increasing
* different forms require different workflows
* the business needs multiple integrations
* the website needs custom validation
* form data needs to be transformed before reaching the CRM

At this point, the question becomes more technical.

It is no longer just:

> “How do I send a form submission to my CRM?”

It becomes:

> “How do I reliably move structured data from my website into the systems that run my business?”

That is where API-based form automation becomes useful.

## A simple architecture to remember

The complete workflow can be represented as:



```text id="y3k7p1"
Visitor
   ↓
WordPress Form
   ↓
Validation
   ↓
Field Mapping
   ↓
API Request
   ↓
Agile CRM
   ↓
CRM Workflow

Each stage has a clear responsibility.

WordPress Form

Collects information from the visitor.

Validation

Ensures that the data is usable.

Field Mapping

Converts website fields into the structure expected by the CRM.

API Request

Transfers the data.

Agile CRM

Stores and manages the contact.

CRM Workflow

Handles the next business process.

This separation makes the system easier to understand and extend.

Final takeaway

Small businesses often begin with simple forms and simple CRM workflows.

That is perfectly reasonable.

But as the business grows, the website may need:

more forms
more fields
more custom data
more integrations
more automation

At that point, native CRM forms may not provide all the flexibility required by the website.

The solution is not necessarily to replace Agile CRM.

Instead, the business can keep Agile CRM as the system for managing contacts and leads while using WordPress forms to create a better website experience.

An API connection can act as the bridge:

WordPress Form
↓
Field Mapping
↓
API
↓
Agile CRM
↓
Business Workflow

This architecture allows the website and CRM to evolve independently while continuing to communicate through a structured data connection.

For Contact Form 7 users who want to connect existing WordPress forms with external APIs and business systems, Contact Form to API provides a way to create that connection without replacing the existing form experience.

You can also learn more about connecting Contact Form 7 with Agile CRM through an API-based workflow in How to Integrate Contact Form 7 with Agile CRM Using API.

Your WordPress Form Works. So Why Is Agile CRM Missing Leads?

Rahul Sharma — Tue, 21 Jul 2026 06:52:19 +0000

A WordPress form can display a successful submission message while the lead never reaches Agile CRM.

The visitor fills out the form.

The browser displays a confirmation message.

The website owner assumes everything worked.

But the notification never arrives.

The contact does not appear in Agile CRM.

The sales team never sees the inquiry.

This is one of the more frustrating WordPress integration problems because the first part of the workflow appears to work.

The form submits successfully.

But the complete workflow may still fail.

A typical lead flow looks like this:

Visitor
   ↓
WordPress Form
   ↓
Form Submission
   ↓
Notification / API Request
   ↓
Agile CRM
   ↓
Contact Record
   ↓
Follow-up

If the lead is missing, the important question is not:

“Why is my form broken?”

The better question is:

“At which stage did the data stop moving?”

That question gives you a much more useful debugging path.

A successful form submission does not prove CRM delivery

Many WordPress forms show a message such as:

Thank you. Your message has been sent.

That message confirms that the form submission was processed by the website.

It does not necessarily confirm that:

an email notification was delivered
an API request was sent
Agile CRM accepted the data
the contact was created
the follow-up workflow started

These are separate operations.

For example:

Form Submission = Successful
API Request     = Failed
CRM Contact     = Not Created

From the visitor's perspective, the form worked.

From the business's perspective, the lead was lost.

This is why form debugging should not stop at the success message.

The email notification workflow has multiple failure points

A traditional workflow often looks like this:

Form Submission
      ↓
Email Notification
      ↓
Someone Reads Email
      ↓
Manual CRM Entry

This process depends on several steps working correctly.

The email needs to be:

triggered
sent
delivered
noticed
processed

Then someone still needs to manually copy the lead into Agile CRM.

Each additional step creates another opportunity for failure.

The email could be delayed.

It could be filtered as spam.

It could be sent to the wrong inbox.

It could arrive when nobody is monitoring the inbox.

The lead could then remain outside the CRM entirely.

Debugging Step 1: Confirm the form received the data

Start with the source.

If you are using Contact Form 7, check the field names in the form:

[text* your-name]
[email* your-email]
[tel your-phone]
[text company]
[textarea your-message]

The submitted field names are:

your-name
your-email
your-phone
company
your-message

Before checking Agile CRM, confirm that WordPress actually receives the expected values.

If the form never receives a value, the API cannot send that value.

This is especially important with forms that include:

required fields
conditional fields
custom validation
JavaScript-generated values
dynamically populated fields

Always begin with the source data.

Debugging Step 2: Confirm the next action was triggered

Once the form submission is confirmed, check what should happen next.

For an email-based workflow:

Form Submission
      ↓
Email Notification

For an API-based workflow:

Form Submission
      ↓
API Request

A successful form submission does not automatically prove that the next action was triggered.

You need to verify the second stage separately.

This is one reason visibility and logging are useful when troubleshooting integrations.

Debugging Step 3: Check the API endpoint

If the form sends data directly to Agile CRM, verify the endpoint first.

A small difference in the URL can cause a request to fail.

For example:

https://api.example.com/contact

may be different from:

https://api.example.com/contacts

A wrong endpoint may return:

404 Not Found

or another error response.

Always verify the exact endpoint required by the API.

Do not assume that a similar-looking URL is valid.

Debugging Step 4: Verify the HTTP method

The endpoint also expects a specific HTTP method.

Common methods include:

GET
POST
PUT
PATCH
DELETE

Creating a new record commonly requires one method, while updating an existing record may require another.

Using the wrong method can result in:

405 Method Not Allowed

The HTTP method should match the API documentation for the endpoint being used.

Debugging Step 5: Check authentication

A request can reach the API and still be rejected because authentication is incorrect.

The API may require:

an API key
a bearer token
a specific authorization header
another authentication mechanism

For example:

Authorization: Bearer YOUR_TOKEN
Content-Type: application/json

If the authorization information is missing or incorrectly formatted, the API may return:

401 Unauthorized

or:

403 Forbidden

A common mistake is having the correct credential but sending it in the wrong format.

The token can be valid while the request is still rejected.

Debugging Step 6: Inspect the payload

The form field names and CRM field names may not be the same.

A Contact Form 7 form might contain:

your-name
your-email
your-phone
company

The receiving system may expect:

name
email
phone
company_name

The integration needs to map the fields:

your-name  → name
your-email → email
your-phone → phone
company    → company_name

The final payload might look like:

{
  "name": "John Doe",
  "email": "john@example.com",
  "phone": "+1 555 123 4567",
  "company_name": "Example Inc."
}

If the payload uses the wrong field names, the receiving API may:

ignore the values
reject the request
create an incomplete contact

This is one of the most common causes of data appearing to disappear during an integration.

The data may have been sent.

The receiving system simply may not know how to interpret it.

Debugging Step 7: Check required fields

WordPress and Agile CRM may have different validation rules.

For example:

WordPress:
email = optional

CRM:
email = required

The form can accept the submission.

The CRM can reject the API request.

This creates a mismatch between the two systems.

When debugging a missing lead, check:

required fields in the form
required fields in the CRM
empty values
data format requirements

A successful WordPress submission does not guarantee that the API will accept the data.

Debugging Step 8: Check custom fields

Many CRM workflows use custom fields.

A form may collect:

company
lead-source
service
budget
project-type

The CRM may store those values using different field identifiers.

The mapping may look like:

lead-source  → CRM custom field
project-type → CRM custom field
budget       → CRM custom field

If the wrong identifier is used, the API may:

ignore the value
return an error
create the contact without the custom data

This can also affect automation.

The contact may be created successfully, but the next workflow may not start because the field required by the automation was never populated.

Debugging Step 9: Read the API response

Do not only check whether the form submitted.

Check what the API returned.

Common response codes can provide useful clues:

400 Bad Request

The request data may be invalid.

401 Unauthorized

Authentication may be missing or invalid.

403 Forbidden

The request may not have the required permission.

404 Not Found

The endpoint may be incorrect.

500 Internal Server Error

The receiving server may have encountered an internal problem.

The exact response depends on the API, but ignoring the response makes debugging much harder.

The response is often the fastest way to identify the failing part of the request.

Debugging Step 10: Verify the actual CRM record

Even if the API returns a successful response, check the contact inside Agile CRM.

Verify:

Was the contact created?
Is the email correct?
Is the name correct?
Was the phone number saved?
Were custom fields populated?
Was a duplicate created?

The API response tells you what the server reported.

The CRM record tells you what actually happened to the data.

Both are important.

The workflow can still fail after contact creation

Creating a contact may not be the final step.

The workflow might continue:

New Contact
    ↓
Apply Tag
    ↓
Assign Lead
    ↓
Start Follow-up

If the contact exists but the follow-up workflow does not start, the problem may be related to:

a missing tag
an incorrect field value
an automation condition
a workflow configuration

This is why the entire workflow needs to be tested.

A successful API request does not necessarily mean the complete business process succeeded.

A practical debugging flow

When a WordPress form submission does not reach Agile CRM, use this sequence:

1. Verify the form data

Did WordPress receive the expected values?

2. Verify the trigger

Was the notification or API action triggered?

3. Verify the request

Was the API request actually sent?

4. Verify the configuration

Check:

endpoint
HTTP method
authentication
headers
payload

5. Verify the response

What status code and response body did the API return?

6. Verify the CRM

Was the contact created correctly?

7. Verify the automation

Did the expected follow-up process begin?

This method is much more effective than repeatedly submitting the form and hoping the next lead appears.

Why an API connection can be useful

A traditional workflow may look like:

Form
  ↓
Email
  ↓
Human
  ↓
CRM

An API-based workflow can reduce the number of manual steps:

Form
  ↓
API Request
  ↓
Agile CRM

This can reduce dependence on:

inbox monitoring
manual copying
manual CRM entry
delayed processing

For WordPress websites using Contact Form 7, Contact Form to API can connect existing form submissions to external APIs and business systems.

The benefit of this type of approach is not simply sending data to another URL.

The integration should make the data flow easier to configure, test, and troubleshoot.

You do not always need to rebuild the form

Many websites already have Contact Form 7 forms with:

custom styling
validation
required fields
spam protection
existing workflows

Replacing the form simply to connect it to a CRM may not be necessary.

A connection layer can allow the existing form to continue collecting data while the API sends the submission to the external system.

The responsibilities remain separate:

WordPress Form
= Collects Data

API Connection
= Sends Data

Agile CRM
= Manages Leads

This can be a more practical approach when the existing form already works well on the website.

A complete checklist

When a WordPress form submits successfully but Agile CRM is missing the lead, check:

Form

Did the visitor submit the form?
Did WordPress receive the data?
Are required fields working?

Trigger

Was the notification triggered?
Was the API request attempted?

API configuration

Is the endpoint correct?
Is the HTTP method correct?
Is authentication valid?
Are the required headers present?

Payload

Is the request body valid?
Are the field names mapped correctly?
Are required CRM fields included?
Are custom fields configured correctly?

Response

What status code was returned?
Did the API accept the request?
Was an error returned?

CRM

Was the contact created?
Is the data complete?
Did the next workflow start?

This checklist helps turn a vague “the CRM didn't get the lead” problem into a structured debugging process.

Final takeaway

When a WordPress form displays a successful submission message but Agile CRM never receives the lead, the form itself may not be the problem.

The failure could happen at any point:

Form Submission
      ↓
WordPress Processing
      ↓
Notification / API Request
      ↓
Authentication
      ↓
Field Mapping
      ↓
Agile CRM
      ↓
Follow-up

The most effective approach is to test each stage separately.

A successful browser message is only one part of the workflow.

The real success condition is:

The submitted data reaches Agile CRM correctly and starts the expected lead process.

For Contact Form 7 users, connecting the existing form to an external API can reduce the number of manual steps between a new submission and CRM entry.

If you want to implement this workflow, see How to Integrate Contact Form 7 with Agile CRM Using API.

Contact Form 7 Submitted Successfully, But Systeme CRM Never Received the Lead: A Practical API Debugging Guide

Rahul Sharma — Mon, 20 Jul 2026 12:44:56 +0000

Your Contact Form 7 form can work perfectly from a user's perspective and still fail to deliver a lead to your CRM.

The visitor fills out the form.

The browser shows a success message.

The WordPress form appears to have submitted correctly.

But when you open Systeme CRM, the contact is nowhere to be found.

This is one of the most confusing problems in form-to-CRM integrations because a successful form submission does not necessarily mean a successful API request.

The complete workflow has multiple stages:

Visitor
   ↓
Contact Form 7
   ↓
WordPress
   ↓
API Request
   ↓
Systeme CRM
   ↓
Contact Record
   ↓
CRM Automation

A failure at any stage can break the workflow.

The key to debugging the integration is to stop treating the form submission as a single event and start checking each stage separately.

First, separate the two different types of success

There are two different questions:

Did Contact Form 7 submit the form?

This is a WordPress-side question.

Did Systeme CRM accept and process the API request?

This is an API and CRM-side question.

These are not the same thing.

A form can successfully collect:

Name: John Doe
Email: john@example.com
Company: Example Inc.

while the API request fails because:

the endpoint is incorrect
authentication is missing
the request method is wrong
the JSON payload is invalid
the CRM expects different field names
a required field is missing

The first debugging step is therefore to identify exactly where the data flow stops.

Step 1: Confirm that Contact Form 7 is collecting the expected data

Start at the beginning.

Look at the form fields:

[text* your-name]
[email* your-email]
[tel your-phone]
[text company]
[textarea your-message]

The important values are the actual field names:

your-name
your-email
your-phone
company
your-message

A common mistake is to assume that the visible label is the field name.

For example:

Visible label: Full Name
Field name:    your-name

The integration needs the submitted field value associated with the actual field name.

Before investigating the CRM, confirm that the form is collecting the expected values.

If the value never exists in the Contact Form 7 submission, no API configuration can send it successfully.

Step 2: Check whether the API request is actually being made

The next question is:

Is WordPress sending a request to the CRM at all?

A successful form submission does not automatically prove that an external API request was made.

The integration needs to send a request to the correct endpoint.

For example:

POST https://api.example.com/contacts

The exact endpoint depends on the API documentation of the destination system.

If the request is sent to:

https://api.example.com/contact

instead of:

https://api.example.com/contacts

the form may still appear to work while the external request fails.

This is why API debugging should begin with the request itself.

Step 3: Verify the HTTP method

APIs usually expect a specific HTTP method.

Common methods include:

GET
POST
PUT
PATCH
DELETE

For creating a new contact, the API may expect POST.

For updating an existing contact, it may expect PUT or PATCH.

Using the wrong method can result in errors such as:

405 Method Not Allowed

or a response that does not perform the expected operation.

The method should always be checked against the API documentation.

Do not assume that every endpoint accepts POST simply because the data is coming from a form.

Step 4: Check authentication and authorization

Authentication is one of the most common reasons an API request fails.

The receiving API may require:

an API key
a bearer token
basic authentication
an OAuth token
a custom authorization header

For example:

Authorization: Bearer YOUR_TOKEN
Content-Type: application/json

If the authorization header is missing or incorrectly formatted, the API may return:

401 Unauthorized

or:

403 Forbidden

These errors mean the request reached the server but was not authorized to perform the requested action.

A common mistake is having the correct token but sending it in the wrong format.

For example, the API may expect:

Authorization: Bearer YOUR_TOKEN

but receive:

Authorization: YOUR_TOKEN

The value may be correct, but the header format is not.

Always check the exact authentication format required by the destination API.

Step 5: Check the request headers

Headers tell the receiving API how to interpret the request.

A JSON API commonly expects:

Content-Type: application/json

The API may also require additional headers for authentication or versioning.

For example:

Content-Type: application/json
Authorization: Bearer YOUR_TOKEN

If the content type is incorrect, the API may not parse the request body as expected.

This can lead to confusing situations where the request technically reaches the server but the API behaves as if the fields are missing.

Step 6: Inspect the JSON payload

This is where many integrations fail.

Suppose Contact Form 7 collects:

your-name
your-email
your-phone

The CRM may expect:

{
  "first_name": "John",
  "email": "john@example.com",
  "phone_number": "+1 555 123 4567"
}

The outgoing payload needs to contain the structure expected by the receiving API.

A payload such as this:

{
  "your-name": "John",
  "your-email": "john@example.com",
  "your-phone": "+1 555 123 4567"
}

may not work if the CRM expects:

{
  "first_name": "John",
  "email": "john@example.com",
  "phone_number": "+1 555 123 4567"
}

The data is present, but the field names are not what the API expects.

This is a field-mapping problem.

Step 7: Check required fields

A CRM may require certain fields before creating a contact.

For example:

email: required
first_name: optional
phone: optional

If the form allows a visitor to submit without an email address, the CRM may reject the request.

The integration should therefore account for:

required fields
optional fields
empty values
validation rules

The form validation and API validation should work together.

A form may consider a field optional while the CRM considers the same information required.

That mismatch needs to be resolved before the integration can be reliable.

Step 8: Check custom field mapping

Custom fields are another common source of problems.

A WordPress form may contain:

company
lead-source
project-type
budget

The CRM may store those values under completely different custom field identifiers.

The integration needs to map:

company      → CRM company field
lead-source  → CRM lead source field
project-type → CRM project type field
budget       → CRM budget field

If the field identifier is incorrect, the API may:

ignore the value
return an error
create the contact without the custom data

This is why field mapping should be tested one field at a time when debugging a complex integration.

Step 9: Check the API response

Do not stop after sending the request.

The response is one of the most useful debugging tools available.

A successful response might indicate that the contact was created.

An error response may tell you exactly what went wrong.

For example:

400 Bad Request

usually indicates a problem with the request data.

401 Unauthorized

usually indicates an authentication problem.

403 Forbidden

usually indicates that the request is not allowed.

404 Not Found

usually indicates an incorrect endpoint.

500 Internal Server Error

indicates a server-side problem that may require further investigation.

The important thing is to inspect the actual response instead of assuming that the form submission was successful.

Step 10: Confirm the CRM contact record

Even when the API returns a successful response, check the actual CRM record.

Verify:

Was the contact created?
Is the email address correct?
Is the name stored correctly?
Are custom fields populated?
Was the contact duplicated?
Was the expected tag applied?

The API response tells you what the server reported.

The CRM record tells you what actually happened to the data.

Both are useful.

Step 11: Confirm the automation after contact creation

Creating the contact is often only the first step.

The next workflow may include:

New Contact
   ↓
Apply Tag
   ↓
Add to Campaign
   ↓
Start Email Sequence

If the contact is created but the expected automation does not run, the problem may be in the automation configuration rather than the API request.

For example, the automation may depend on:

a specific tag
a specific field value
a form subscription event
a campaign enrollment action

A successful contact creation does not automatically guarantee that the next workflow will start.

Test the entire chain.

A practical debugging checklist

When a Contact Form 7 to Systeme CRM integration is not working, check the following:

Form

Does Contact Form 7 receive the expected values?
Are required fields validated?
Are the field names correct?

Endpoint

Is the API URL correct?
Is the correct API version being used?
Is the endpoint available?

Request

Is the HTTP method correct?
Are the required headers present?
Is the content type correct?

Authentication

Is the API key or token valid?
Is it being sent in the correct header?
Does the token have the required permissions?

Payload

Is the JSON valid?
Are the field names correct?
Are custom fields mapped correctly?
Are required fields included?

Response

What HTTP status code was returned?
What error message did the API provide?
Was the request accepted?

CRM

Was the contact created?
Is the data correct?
Did the expected automation start?

This checklist is much more effective than repeatedly submitting the form and hoping that the next attempt works.

The challenge of writing custom integrations

Developers can build the entire workflow manually.

A custom implementation may need to:

hook into the Contact Form 7 submission
retrieve the submitted values
map the fields
build the JSON payload
configure authentication
send the API request
handle the response
log errors

This is a reasonable approach when the integration is highly customized.

However, the same process needs to be repeated whenever another form or API is introduced.

For WordPress sites that need a reusable configuration layer, a direct API connector can handle the endpoint, HTTP method, headers, authentication, field mapping, payload, and request logging.

Contact Form to API is designed around this type of Contact Form 7 to external API workflow, allowing an existing WordPress form to send data to external systems without requiring a completely new form implementation.

The important point is that the integration should make the data flow easier to inspect and troubleshoot.

The real lesson: debug the data flow, not just the form

When a CRM does not receive a Contact Form 7 submission, the first instinct is often:

“The form integration is broken.”

That description is too broad.

A better debugging question is:

“At which point did the data stop moving?”

Did Contact Form 7 collect the data?

Did WordPress trigger the API request?

Did the request use the correct endpoint?

Did authentication succeed?

Was the payload valid?

Did the API accept the fields?

Was the contact created?

Did the automation start?

Breaking the workflow into these individual questions makes the problem much easier to solve.

Final takeaway

A successful Contact Form 7 submission is only the beginning of a form-to-CRM workflow.

The complete integration needs to move data through several stages:

Contact Form 7
   ↓
WordPress
   ↓
Field Mapping
   ↓
Authentication
   ↓
API Request
   ↓
Systeme CRM
   ↓
Contact Record
   ↓
Automation

If a lead is missing from the CRM, check each stage instead of treating the entire integration as one black box.

Once the endpoint, request, authentication, payload, response, contact record, and automation are checked separately, most integration problems become much easier to identify.

For a complete implementation guide focused specifically on the WordPress setup, see How to Connect Contact Form 7 with Systeme CRM in WordPress.

CF7 + ActiveCampaign Stopped Working After an Update And the Plugin Author Went Silent

Rahul Sharma — Fri, 17 Jul 2026 07:25:12 +0000

A site owner posted on the WordPress forums with a simple problem. Their CF7 to ActiveCampaign integration had stopped working. Contacts from forms were no longer being added to their ActiveCampaign lists. The plugin had just been updated to version 1.1 and nothing was going into ActiveCampaign after that.

The plugin author replied three weeks later asking when exactly it stopped working.

Four months after the original post, a second user appeared with the same problem. Then they added something that changes the entire story:

"My company purchased the pro version a year ago. It said lifetime updates. Now that the plugin stopped working due to WP core updates, I tried to download the latest version. The download link has expired. The price back then was $20, now it is $69. I think you are trying to force existing customers to pay the higher price."

The plugin author never responded again. The thread was closed as resolved. Nothing was resolved.

What Actually Happened Here

Two things broke simultaneously and neither was fixed.

The first was a technical failure. The dedicated CF7 to ActiveCampaign plugin stopped sending data after a WordPress core update. This is a known risk with any plugin that hooks into CF7's submission process — when WordPress or CF7 updates change internal function signatures, hook priorities, or REST API behaviour, plugins that depend on those internals can break silently. No error message. No failed notification. The form submits successfully and ActiveCampaign receives nothing.

The second was a business failure. The plugin was sold with a lifetime updates promise at $20. The developer later raised the price to $69 and appears to have let existing licence holders' download access expire. When the plugin broke from a WP update, the customers who paid for lifetime updates could not get the fix.

Both failures are real. Both are preventable. And both point to the same underlying problem: relying on a single dedicated plugin to maintain a business-critical CRM integration.

Why Dedicated Plugins Break After WordPress Updates

When WordPress releases a major update, things change under the hood. Hook names, function signatures, REST API behaviour, and nonce handling can all shift between versions. Plugin authors who are actively maintaining their code update their plugin to stay compatible. Plugin authors who have moved on, lost interest, or changed their pricing model do not.

A CF7 to ActiveCampaign plugin that was written in 2019 and last updated in 2020 is almost certainly using internal CF7 functions and hook names that have changed since then. When the update runs, the plugin's hook either fires at the wrong time, fires with the wrong arguments, or does not fire at all. The result is always the same: CF7 forms submit successfully, Flamingo logs the entry, and ActiveCampaign receives nothing.

The tricky part is that there is usually no visible error. The form works from the user's perspective. The CRM is silent. You might not notice for days or weeks.

How to Diagnose a Silent Failure

Before switching anything, confirm that the integration is actually broken and not just delayed or filtered.

Enable WordPress debug logging if it is not already on. Add this to wp-config.php:

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

Submit a test form and immediately check wp-content/debug.log. If the plugin is throwing a PHP error during the hook execution, it will appear here. Common errors after WP updates include calls to deprecated functions, undefined method calls, and argument count mismatches.

Also check whether CF7 itself updated at the same time as WordPress. CF7 frequently releases updates alongside major WordPress releases. If CF7 changed the hook your plugin uses, the plugin needs to be updated to match.

If debug.log shows nothing from the plugin at all, the hook is not firing. That means the plugin either deregistered itself on error or was never registered in the first place due to a PHP fatal that happened before the hook registration ran.

The Structural Problem With Dedicated Integration Plugins

The second user's complaint about lifetime updates and expired download links is not an isolated incident. It is a pattern in the WordPress plugin ecosystem.

A developer builds a CF7 to CRM plugin, sells it, supports it for a while, and then either raises prices, abandons it, pivots their business, or simply stops maintaining it. Customers who paid for a specific integration are left with a plugin that no longer works and no path forward except paying again or finding an alternative.

This is the structural risk of relying on a dedicated integration plugin for a business-critical connection between your website and your CRM. You are not just dependent on the technical quality of the plugin. You are dependent on the business decisions of a single developer or small team.

The More Resilient Alternative

Contact Form to API takes a fundamentally different approach. Instead of a plugin that manages the ActiveCampaign connection on your behalf with its own proprietary implementation, you configure a direct API call from WordPress to ActiveCampaign's REST API.

The plugin sends an HTTP request to ActiveCampaign's endpoint with your field mapping and API key. ActiveCampaign receives it and creates or updates the contact. There is no proprietary middleware, no internal CF7 hooks that can break on CF7 updates, and no dependency on a single developer staying active.

When WordPress updates, the plugin continues to work because it is calling a standard HTTP endpoint, not relying on internal WordPress or CF7 functions that change between versions. When ActiveCampaign updates their API, you update the endpoint URL in your settings. No waiting for a plugin author to release a patch.

The ActiveCampaign API endpoint for creating a contact is:

POST https://youraccountname.api-us1.com/api/3/contacts
Api-Token: YOUR_API_KEY
Content-Type: application/json

{
  "contact": {
    "email": "jane@example.com",
    "firstName": "Jane",
    "lastName": "Smith",
    "phone": "1234567890"
  }
}

You map your CF7 fields to these keys in the Contact Form to API settings. Every submission calls this endpoint directly. The response is logged so you can confirm each contact was created.

What to Do Right Now If Your Integration Is Broken

If your CF7 to ActiveCampaign integration stopped working after an update, go through these steps.

Check the plugin's last update date in your WordPress admin. If it has not been updated in over a year, it is likely incompatible with recent WordPress or CF7 versions.

Enable WP_DEBUG_LOG and submit a test form. If the plugin logs a PHP error, that confirms it is broken and needs to be either updated or replaced.

Check whether the plugin author is still responding to support threads. Search the plugin's support forum for recent threads and look for replies from the author in the last three to six months.

If the author is inactive and the plugin is broken, do not wait for a fix that may never come. Your leads are not reaching your CRM right now and every day you wait is more contacts lost.

Summary

A dedicated CF7 to ActiveCampaign plugin breaking after an update is a technical problem with a business cause. The technology changed and the plugin author did not keep up. The fix is not to find another dedicated plugin with the same structural risk. The fix is to use a direct API integration that does not depend on a plugin developer staying active and compatible through every WordPress and CF7 release.

HubSpot Is Capturing Your CF7 Submissions Automatically But the Data Is a Mess

Rahul Sharma — Wed, 15 Jul 2026 11:52:56 +0000

A WordPress site owner posted on the HubSpot community forum with a mystery. They had not set up any integration between Contact Form 7 and HubSpot. The only HubSpot code on their site was the chat widget script in the footer. Yet HubSpot was somehow collecting CF7 form submissions and creating entries labelled .wpcf7-form, .submitting. They had deleted the integration three times and it kept coming back.

The HubSpot community moderator explained what was happening: a HubSpot feature called Non-HubSpot Forms was enabled on their account. This feature runs a script that scans every page on your site where the HubSpot tracking code is installed and automatically captures any form submission it detects, including CF7 forms. No setup required on your end. HubSpot just takes it.

That sounds convenient until you look at what it actually captures.

What Non-HubSpot Forms Captures (And What It Misses)

When HubSpot's tracking script auto-captures a CF7 submission, it takes what it can see from the page: the form field values that were submitted. But it has no knowledge of your CF7 form's structure, your field naming conventions, or which fields map to which HubSpot contact properties.

What HubSpot receives looks something like this — a flat, unstructured set of values with no meaningful property mapping. The contact gets created in HubSpot but with fields that do not align to your HubSpot contact properties, no lifecycle stage set, no list assignment, no tagging, and no automation triggered.

You get a contact record that exists but is essentially useless for any workflow, pipeline, or follow-up automation you have set up in HubSpot.

How to Stop the Ghost Captures

Disabling Non-HubSpot Forms stops HubSpot's tracking script from auto-capturing CF7 submissions.

In your HubSpot account, go to Marketing, then Forms, then click the Non-HubSpot Forms option in the left sidebar. Toggle off "Collect data from external forms." Save.

Once disabled, the ghost entries stop appearing. The existing ones will remain in HubSpot but no new ones will be created from CF7 submissions.

Now you have a clean slate. The question is what to replace it with.

The Right Way to Send CF7 Data to HubSpot

Instead of letting HubSpot's tracking script grab whatever it can see, send exactly what you want HubSpot to receive with full control over how it maps to your contact properties.

HubSpot's Contacts API accepts a POST request with a structured payload where you specify exactly which HubSpot properties receive which values from your CF7 form:

{
  "properties": {
    "email": "jane@example.com",
    "firstname": "Jane",
    "lastname": "Smith",
    "phone": "1234567890",
    "company": "Acme Corp",
    "lifecyclestage": "lead",
    "hs_lead_status": "NEW"
  }
}

This creates a proper HubSpot contact with the right properties populated, the right lifecycle stage set, and the right conditions to trigger your HubSpot workflows and automations.

Contact Form to API handles this from the WordPress dashboard. You set the HubSpot Contacts API endpoint, add your HubSpot Private App token as a Bearer header, and map each CF7 field to the correct HubSpot property name. Every form submission creates a properly structured contact in HubSpot with the fields you defined, not a ghost entry with unrecognised field labels.

Why This Is Better Than the Tracking Script Approach

The Non-HubSpot Forms feature exists for convenience. It is designed for people who do not want to set up a proper integration and are happy with approximate data. For a business where HubSpot is the actual CRM driving sales and follow-up, approximate data creates noise, not value.

When you send CF7 data through a direct API integration, you control exactly which contact properties are set, which lifecycle stage the contact enters, and which workflows trigger. You can set hs_lead_status to NEW so the lead appears in your sales queue immediately. You can set lifecyclestage to lead or marketingqualifiedlead depending on which form they submitted. You can pass UTM parameters, page URLs, or custom field values that the tracking script cannot capture.

The ghost entries from Non-HubSpot Forms will never give you that level of control. They are a passive capture mechanism. A direct API integration is an active, intentional one.

Setting Up the HubSpot Private App Token

HubSpot moved from legacy API keys to Private App tokens. To call the Contacts API from your WordPress site, you need a Private App token.

In HubSpot, go to Settings, then Integrations, then Private Apps. Create a new private app and give it the crm.objects.contacts.write scope at minimum. Copy the generated token. This is what goes in the Authorization header as Bearer YOUR_TOKEN.

The HubSpot Contacts API endpoint to create or update a contact is:

POST https://api.hubapi.com/crm/v3/objects/contacts

For updating an existing contact by email (upsert behaviour), use:

PATCH https://api.hubapi.com/crm/v3/objects/contacts/{contactId}

Or use the search endpoint to find a contact by email first, then update if found.

Summary

Non-HubSpot Forms is why HubSpot captures CF7 submissions without any integration being set up. The data it captures is shallow and unstructured. Disable it under Marketing > Forms > Non-HubSpot Forms to stop the ghost entries.

Then replace it with a direct API integration that sends structured, mapped data to HubSpot's Contacts API. That gives you real contact records with the right properties, lifecycle stages, and workflow triggers — which is what HubSpot is actually built for.

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

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

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

No error. No failed notification. Just silence.

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

Reason 1: The API Token Has Insufficient Scopes

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

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

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

Reason 2: The Base ID or Table Name Is Wrong

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

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

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

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

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

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

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

Reason 4: The Plugin Is Catching a Silent Error

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

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

Reason 5: CF7 Is Flagging the Submission as Spam

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

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

A More Reliable Way to Connect CF7 to Airtable

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

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

Checklist Before Debugging Further

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

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

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

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

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

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

Temporarily disable Akismet and retest to rule out spam flagging.

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

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

A developer updated their client's WordPress site to 5.3.2 and updated the CF7 Salesforce plugin at the same time. Both updates completed without issue. But from that point on, no new records were being created in Salesforce. The Salesforce log showed this:

Data Sent: Nothing posted to Salesforce
Message: POST requires content-length
errorCode: UNKNOWN_EXCEPTION

The form itself was working fine. Flamingo showed every submission. Salesforce received nothing.

The plugin author said to check field mapping. The developer adjusted the mapping and it worked again. But neither the forum post nor the plugin author explained why a WordPress update would break a field mapping that was working perfectly before.

This post explains exactly what happened, what the error message actually means, and how to build a CF7 to Salesforce integration that does not break when WordPress updates.

What "POST requires content-length" Actually Means

The error POST requires content-length is a Salesforce API error, not a WordPress error. It means the HTTP request that arrived at Salesforce's endpoint had an empty or missing body. Salesforce expected a JSON payload with lead data and received nothing.

This does not happen because WordPress updated. WordPress updates do not change how form data is collected or how field mapping works. What actually happened is that the plugin update that ran at the same time reset or altered the field mapping configuration.

When a plugin updates, it can reset custom settings if the update involves schema changes to how settings are stored. The developer's field mapping was wiped or changed by the plugin update, not by the WordPress update. The form submitted successfully, the plugin tried to POST to Salesforce, sent an empty body because no fields were mapped, and Salesforce returned the content-length error.

Why Field Mapping Breaks Silently

The CF7 Salesforce plugin passes the form's submitted data to Salesforce based on the mapping you configure. Each CF7 field tag gets mapped to a Salesforce field name like FirstName, LastName, Email, Company.

When the mapping is correct, the plugin builds a JSON body like this:

{
  "FirstName": "Jane",
  "LastName": "Smith",
  "Email": "jane@example.com",
  "Company": "Acme Corp"
}

When the mapping is empty or broken, the plugin sends this:

{}

Salesforce receives an empty object. Its validation requires LastName at minimum for a Lead record. No LastName and no content in the body means the request fails with the content-length error. The plugin logs "Nothing posted to Salesforce" because the payload was genuinely empty.

The issue is that this fails silently from the user's perspective. The form shows success. Flamingo logs the submission. Nothing in the UI indicates that the Salesforce write produced an empty payload.

How to Verify Your Field Mapping After Any Plugin Update

After updating any CF7 CRM integration plugin, always open the plugin's field mapping settings and confirm your mappings are still in place before assuming the integration is working.

For the CF7 Salesforce plugin specifically, go to the form settings and open the Salesforce Feeds or Mapping section. Confirm every required Salesforce field (FirstName, LastName, Email, Company) has a CF7 form field mapped to it. Submit a test form and check the Salesforce log immediately for the status.

If the log shows a Salesforce ID being returned, the record was created. If it shows N/A with the content-length error, your mapping is empty.

The Longer-Term Problem: Integration Fragility

The real issue here is not a bug. It is fragility. A plugin update wiped a mapping configuration that was working correctly. The integration broke silently. Leads were lost until someone noticed.

This is a structural problem with dedicated CF7 CRM plugins that store your integration configuration in their own database schema. When they update that schema, existing configurations can be reset, altered, or orphaned.

Contact Form to API takes a different approach. Your integration is configured as a direct API request with an explicit JSON payload body. The field mapping lives in a request body you define, like this:

{
  "FirstName": "[your-name]",
  "LastName": "[last-name]",
  "Email": "[your-email]",
  "Company": "[your-subject]"
}

This mapping does not live in a proprietary database schema that can be reset by a plugin update. It is part of your integration configuration that you define and control. When you update the plugin, your payload definition stays intact. A 201 response in the API logs confirms every record was created successfully in Salesforce.

The Pro version with the OAuth Add-on handles Salesforce's OAuth 2.0 authentication flow directly from WordPress, connecting to Salesforce's Lead API at POST /services/data/v63.0/sobjects/Lead/ without any Zapier or middleware dependency.

Salesforce Required Fields That Must Always Be Mapped

Salesforce requires at minimum one field for a Lead record to be created. In practice you need at least LastName and Company. Without these, Salesforce returns a validation error regardless of whether the other fields are correct.

Make sure these are always in your mapping:

CF7 Field	Salesforce API Field	Required
Name field	`LastName`	Yes
Company field	`Company`	Yes
Email field	`Email`	Recommended
Phone field	`Phone`	Optional

If your CF7 form does not have separate first name and last name fields, map your full name field to LastName. Salesforce will accept it.

Checklist After Any WordPress or Plugin Update

Before trusting that your Salesforce integration survived an update, go through this list.

Open the field mapping settings in your CF7 Salesforce plugin and confirm all mappings are present.

Submit a test form with real-looking data, not just "test test@test.com."

Check the Salesforce log immediately and confirm a Salesforce ID was returned.

Log into Salesforce and search for the test contact you just submitted to confirm it actually appears as a Lead record.

If any step fails, check the mapping first before investigating anything else.

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

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

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

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

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

Here are the four real reasons this happens.

Cause 1: Google Sheets API Rate Limiting

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

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

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

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

Cause 2: PHP Execution Timeout

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

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

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

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

Cause 3: WP Rocket Caching the Form Submission

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

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

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

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

Cause 4: Google OAuth Token Expiry Mid-Session

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

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

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

The Reliable Alternative: Direct API Integration

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

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

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

Diagnosing Which Cause You Are Hitting

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Why Re-Authorizing Doesn't Actually Fix It

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

Sidestepping the Whole Problem

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

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

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

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

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

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

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

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

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

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

Troubleshooting Checklist

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

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

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

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

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

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

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

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

What "Necessary Fields Are Missing" Actually Means

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

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

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

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

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

Why This Keeps Tripping People Up

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

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

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

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

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

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

The Brevo API endpoint for this is:

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

With a body like this:

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

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

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

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

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

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

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

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

Summary

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

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