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:
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
Failed request
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, 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.
SOCIAL SHARE CARD GENERATOR