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.
Top comments (0)