When Every Vendor Says Their System Works

The form provider says the submission was successful.

The CRM vendor says nothing reached its system.

The email provider says there are no delivery problems.

The website developer says the site is working.

The hosting company says the server is healthy.

Meanwhile, the lead is still missing.

This is one of the most frustrating kinds of technical problem because every vendor may be telling the truth. Their individual system may be operating exactly as expected. The failure can still exist somewhere between them.

That distinction matters.

Most vendors can only see the part of the process they control. A form company may confirm that its software accepted a submission. That does not prove the submission reached the webhook, entered the CRM, triggered the correct workflow, created the right record, notified the assigned employee, or appeared correctly in analytics.

When several systems participate in one business process, component-level success does not prove that the process succeeded.

The only reliable way to diagnose the failure is to stop asking which vendor is wrong and start tracing what happened to one specific transaction. When the workflow spans several systems and nobody has a complete map, an independent technical website assessment can help establish where the failure actually occurs.

Why multi-vendor failures are so difficult to diagnose

Modern websites are rarely self-contained.

A fairly ordinary lead-generation process might involve:

1. A visitor submits a form on the website.
2. The form validates the information.
3. The website sends the submission to a third-party service.
4. A webhook or API passes the data into a CRM.
5. The CRM creates or updates a contact.
6. An automation assigns the lead to a salesperson.
7. An email platform sends a confirmation.
8. An internal notification reaches the appropriate employee.
9. Google Analytics records the event.
10. Google Ads receives the conversion.

The visitor sees one form. Behind it may be six companies, several accounts, and a chain of rules nobody has documented in one place.

Every additional provider creates another boundary where data can be transformed, delayed, rejected, duplicated, or lost. It also reduces the amount of the workflow any one vendor can see. Research on multi-vendor technology environments describes this same accountability problem: each provider has visibility into its own layer, while resolving an issue may require working across the application, network, hosting, security, and integration layers.

This creates a predictable support cycle:

“Everything looks good on our end.”

That statement may only mean the vendor’s dashboard is green.

It does not tell you whether the business outcome occurred.

A green dashboard is not proof that the integration works

Vendor status pages are useful for identifying widespread outages. They are much less useful for diagnosing a failure affecting one account, endpoint, workflow, record type, or combination of settings.

An API can be available while rejecting your credentials.

A webhook service can be online while delivering events to an outdated URL.

A CRM can be functioning while a workflow ignores records that do not meet one hidden condition.

An email provider can be operational while your messages fail authentication or route into spam.

A form can display a success message before a separate background request fails.

A useful integration health check must verify the transaction from beginning to end.

For a lead form, “working” should mean something closer to:

• The visitor successfully submitted the form.
• The original data was saved somewhere recoverable.
• The correct CRM record was created or updated.
• The lead was assigned correctly.
• Required notifications were sent.
• The visitor received the expected confirmation.
• Attribution data remained attached.
• The conversion was recorded once.

A vendor may be able to confirm one item on that list. Someone still needs to confirm the whole list.

Start with one transaction, not the entire system

When a client brings me a problem involving several vendors, I usually ask for one specific example first.

Not “leads have been missing lately.”

I need something like:

• The exact date and time
• The person’s name or email address
• The page or form used
• The expected outcome
• What actually happened
• Any confirmation messages received
• Any record that did appear in one of the systems
• Whether the problem can be reproduced

One real transaction gives everyone something concrete to trace.

Without it, each vendor tends to perform a generic health check. They confirm the account is active, scan for obvious outages, and send the ticket back.

With a specific transaction, you can ask precise questions:

• Does the form system show this submission?
• Was a webhook generated for it?
• What URL received the webhook?
• What response code came back?
• Did the CRM receive a request with this email address?
• Was the record rejected, merged, or filtered?
• Did the automation enroll the record?
• Which condition prevented the next step?
• Was a notification generated?
• What message ID did the email provider assign?
• Did the analytics event contain the expected identifiers?

That turns a vague dispute into an investigation.

Map the workflow before changing anything

Do not begin by replacing plugins, reconnecting accounts, regenerating keys, or rebuilding the form.

First, draw the workflow.

It does not need to be a sophisticated system diagram. A basic map might look like this:

Website form → webhook → automation platform → CRM → lead assignment → internal email

Then add any parallel paths:

Website form → GA4 → Google Ads

CRM → customer confirmation email

CRM → internal Slack notification

For each connection, document:

• What triggers it
• What information is sent
• Which account owns it
• How the receiving system identifies the record
• What response confirms success
• Where errors are logged
• Whether retries occur
• Who has access
• Who is responsible for maintaining it

This step often reveals the problem before any debugging begins.

I have seen workflows where two vendors believed the other system owned a connection that was actually running through a third automation platform. I have also found integrations tied to former employees’ accounts, old staging URLs, expired credentials, and workflows that nobody knew were still active. These are also common issues to review when you inherit a website from another team or provider.

You cannot diagnose a system accurately when the system itself has not been documented. Our guide to taking over a website built by another developer explains how to approach that wider investigation before changing an inherited system.

Find the last confirmed successful step

Once the workflow is mapped, work forward from the beginning.

Ask a simple question at every stage:

Can we prove that this exact transaction completed this step?

Suppose a form submission never appeared in the CRM.

Step 1: Did the website receive the submission?

Look for:

• A saved form entry
• A database record
• A server log
• A confirmation email
• A timestamped request
• A unique submission ID

When no record exists at the first step, the problem is likely within the website, browser, form validation, or request handling.

When the form system contains the submission, move forward.

Step 2: Did the website attempt to send it?

Look for:

• Webhook delivery history
• API request logs
• Automation run history
• Outbound request records
• A request ID
• The destination URL
• The request payload

A successful form submission does not guarantee that a webhook was sent.

Conditional logic may have prevented it. The webhook action may be disabled. The request may have been routed only for certain answers. The site may still be sending to a test account or old endpoint.

Step 3: Did the receiving system accept it?

Look for the response.

HTTP status codes provide an important clue:

• 200 through 299 generally indicate that the request was accepted successfully.
• 400 usually indicates an invalid or malformed request.
• 401 usually points to missing or invalid authentication.
• 403 indicates that the identity is recognized but lacks permission.
• 404 may mean the endpoint no longer exists.
• 429 indicates that the integration exceeded a rate limit.
• 500 through 599 indicate a server-side failure.

A 200 response still does not always mean the business action completed. Some systems acknowledge the request before processing it asynchronously.

You may need to trace the record inside the destination system.

Step 4: Did the receiving system process the record correctly?

The CRM may have accepted the request and then:

• Rejected one field
• Merged the lead into an existing contact
• Created the wrong object type
• Assigned the wrong owner
• Excluded it from an automation
• Stored it without attribution data
• Marked it as spam
• Failed on a later workflow action

This is the point where support teams often talk past each other.

The sending vendor says, correctly, “We received a success response.”

The CRM says, correctly, “No new contact was created.”

Both statements can be accurate if the CRM accepted the request but merged, filtered, or rejected the record during later processing.

Common places integrations fail

Although every setup is different, the same categories appear repeatedly.

Authentication and permissions

Connections frequently depend on:

• API keys
• OAuth tokens
• Refresh tokens
• Service accounts
• User permissions
• SSL certificates
• Shared secrets
• Webhook signatures

Credentials can expire, be revoked, lose access, or remain tied to a user who has left the company.

A connection may also be partially authorized. It can read contacts but not create them, access one account but not another, or operate until a newly required permission is introduced.

A 401 response usually points toward missing or invalid credentials. A 403 often means the credentials are valid but do not permit the requested action.

Do not assume that clicking “Reconnect” solves the underlying problem. Confirm which account was connected, which permissions were granted, and which environment the credentials belong to.

Data mapping and schema changes

Two systems may use different names or formats for the same information.

One expects:

first_name

Another sends:

firstname

A CRM may require a number while the form sends formatted text. A dropdown may send the visible label when the receiving system expects an internal ID. A date may arrive in the wrong format. A required field may have been added after the integration was built.

Sometimes the integration fails loudly with an error.

Sometimes it quietly drops the field and continues.

This is why the raw request payload and raw response are so useful. They show what the systems actually exchanged, rather than what the interface suggests happened.

Conditional logic

Conditional workflows are excellent at creating failures that look random.

A lead may only route correctly when:

• A certain service is selected
• A state matches an approved territory
• A consent checkbox is checked
• A contact does not already exist
• The email domain is not blocked
• A budget field exceeds a threshold
• A lead source contains the expected value
• A user has a specific role
• An appointment belongs to the correct location

When some submissions work and others do not, compare the data.

The difference between a successful transaction and a failed transaction is often the fastest path to the cause.

Rate limits and volume spikes

An integration may work during normal traffic and fail during a campaign, event, sale, or bulk import.

Many platforms limit how many requests an application can send within a period. A system that exceeds the limit may receive a 429 Too Many Requests response, sometimes with instructions indicating when it can try again.

The integration then needs a sensible response:

• Queue requests
• Slow down
• Retry later
• Respect the vendor’s wait period
• Preserve the original transaction
• Prevent duplicate processing

Without those controls, records may disappear whenever traffic exceeds normal levels.

Webhook retries and duplicate records

Webhooks are often retried when the sending system does not receive a successful response quickly enough.

This is normal behavior.

It also means the receiving system must be prepared to see the same event more than once.

Stripe, for example, warns that webhook events may be retried and may arrive out of order. Its documentation recommends that receiving systems avoid depending on a guaranteed sequence.

Without duplicate protection, one legitimate transaction can create:

• Two contacts
• Two orders
• Two payments
• Multiple notifications
• Repeated tasks
• Conflicting updates

A duplicate does not necessarily prove the sender malfunctioned. It may mean the first request was processed but the acknowledgement did not reach the sender in time.

Environment mismatches

Development, staging, and production environments frequently become mixed together.

Common examples include:

• A production form sending to a sandbox CRM
• A webhook pointing to an old staging URL
• Test credentials installed on the live site
• Different field IDs between CRM environments
• A development endpoint that no longer exists
• Analytics preview settings left in place
• A callback URL that only matches one domain

These failures can be especially confusing because each individual account appears healthy.

The systems are simply connected to the wrong version of each other.

Email delivery mistaken for an integration failure

Sometimes the data reached the destination correctly, but nobody was notified.

The CRM record exists. The workflow ran. The internal email did not arrive.

That is no longer a form-to-CRM problem.

The investigation has moved into:

• Email authentication
• Sending-domain configuration
• Suppression lists
• Spam filtering
• User mailbox rules
• Distribution-group permissions
• Invalid addresses
• Notification settings
• Email provider logs

Tracing the complete workflow prevents everyone from continuing to troubleshoot the form after the failure has already been narrowed to email delivery.

Tracking failures that do not affect the real transaction

The reverse can also happen.

The lead reaches the sales team, but Google Ads reports no conversion.

The booking succeeds, but GA4 does not record the purchase.

The form works, but Tag Manager listens for the wrong event.

That is a measurement failure, not necessarily an operational failure.

This distinction matters because the business may react to bad tracking by replacing a system that is actually working. Before approving a major project, confirm whether the right path is to repair, rebuild, or migrate the website.

Always separate these questions:

1. Did the business action occur?
2. Was the business action measured correctly?

They often require different investigations.

Use evidence that every vendor can recognize

A productive support ticket should give the vendor enough information to search its own logs.

Include:

• Exact timestamp with timezone
• Source account
• Destination account
• Endpoint or workflow name
• Record identifier
• Submission or event ID
• Request ID
• Relevant email address
• HTTP response code
• Sanitized payload
• Error message
• Screenshot when useful
• Steps already tested
• Expected result
• Actual result

Unique identifiers are particularly valuable because modern tracing systems use request and correlation IDs to connect events across different components. Distributed tracing is built around following one request through its individual steps so engineers can identify where it failed or slowed down.

Compare these two vendor tickets.

Weak ticket

The integration is broken. Leads are not coming through. Please fix this.

Useful ticket

At 2:14:37 p.m. Eastern on July 27, a submission for jane@example.com entered Form 12 and received submission ID 18492. The webhook delivery log shows a POST to the CRM endpoint at 2:14:39 with request ID abc123. The endpoint returned HTTP 200, but no matching contact or activity appears in the CRM. Other submissions before 1:50 p.m. processed normally. Please search for request ID abc123 and confirm how the payload was handled after acceptance.

The second ticket makes it much harder to respond with a generic status-page link.

Do not ask vendors to prove innocence

The goal is not to catch one vendor lying.

Ask each vendor to prove the transaction’s path through its system.

Useful questions include:

• What is the last log entry you have for this transaction?
• What identifier should the next system have received?
• What exact response did your system return?
• Was the transaction queued for later processing?
• Was the record filtered, merged, or rejected?
• Which workflow condition applied?
• Did a retry occur?
• Did your platform recently change an endpoint, field, permission, or rate limit?
• Can you provide a request or event ID for the next vendor?
• What evidence would you need from the other system to continue?

This keeps the conversation technical and reduces the temptation to make unsupported claims.

It also recognizes that vendors may genuinely lack visibility beyond their boundary.

Who should own the investigation?

Someone needs to own the outcome even when no single vendor owns the entire system. For businesses dealing with an inherited or undocumented setup, that may require website takeover and technical rescue support that looks across the complete workflow.

That person does not have to personally maintain every platform. They do need enough access and technical understanding to:

• Map the workflow
• Identify the participating systems
• Gather logs and identifiers
• Test each boundary
• Keep a shared timeline
• Ask precise questions
• Compare vendor responses
• Document the final cause
• Confirm the business outcome after the fix

Without an investigation owner, every vendor works its own ticket independently. Information gets lost between support portals. Each team repeats the same basic checks. Nobody notices that two vendors are using different timestamps, identifiers, accounts, or definitions of success.

Formal responsibility matrices can help prevent this. Even API providers with established integration programs publish explicit shared-responsibility documentation defining who controls credentials, monitoring, access reviews, and third-party oversight.

Small organizations do not need a complicated governance program. They should still know who owns each connection and who leads when the entire workflow fails.

An anonymized example: the form worked, but the workflow did not

A client had a website form that appeared to submit normally.

The form entry was saved. The visitor received confirmation. The website showed no error.

However, internal messages were being routed incorrectly, and the expected information was not consistently reaching the right people.

It would have been easy to call this a broken form.

The actual workflow crossed several layers:

• Conditional form fields
• Different notification recipients
• An external platform
• CRM properties
• Internal email routing
• User responses after submission

The problem could not be understood by checking whether the form displayed a success message. We had to map what each answer was supposed to trigger, where the information moved, and how later replies should relate to the original record.

The solution required changes across the workflow rather than replacing the form itself.

The important lesson was simple:

A submission can succeed technically while the business process fails.

Another example: the booking succeeded, but the ad platform saw nothing

In another situation, customers were completing purchases through a booking system embedded inside the main website.

The booking platform recorded the transactions.

The advertising account did not.

Several systems could reasonably say their part was working:

• The website loaded the booking tool.
• The booking platform completed the sale.
• Google Ads received normal website traffic.
• The tag appeared to be installed.

The missing piece was the handoff between the embedded booking environment and the website’s measurement setup.

This type of problem requires tracing both the customer journey and the data journey. The customer can successfully finish the purchase while the marketing platform never receives a valid conversion event.

Replacing the booking platform would have addressed the wrong problem.

What to do before opening five support tickets

Use this sequence:

1. Write the expected workflow

Describe what should happen from the user’s action through the final business outcome.

2. Choose one failed example

Record the exact time, identifier, and expected result.

3. Identify the last confirmed successful step

Do not assume a step succeeded because its interface looks normal.

4. Collect raw evidence

Gather logs, payloads, response codes, workflow history, message IDs, and screenshots.

5. Compare a failed transaction with a successful one

Look for differences in fields, timing, account, routing, permissions, and volume.

6. Check recent changes

Review:

• Software updates
• Credential changes
• Staff changes
• New fields
• Workflow edits
• Platform migrations
• DNS changes
• Domain changes
• API version changes
• New campaigns or traffic spikes

7. Contact the vendor nearest the failure

Give that vendor the transaction details and ask what happened next.

8. Carry identifiers across vendor boundaries

Ask Vendor A for the ID Vendor B can search.

9. Test the complete outcome after the fix

Do not stop when one dashboard turns green.

10. Document the workflow

Record the cause, resolution, owners, credentials, dependencies, and monitoring process.

How to make integrations easier to support

Some failures cannot be prevented. They can still be made much easier to diagnose. When every repair adds another workaround or undocumented dependency, the wider system may also be too fragile to keep repairing safely.

Save the original data

Do not allow the only copy of a lead, order, or application to exist inside a chain of live API calls.

Keep a recoverable source record where appropriate.

Log every handoff

Record:

• When the request was sent
• Where it was sent
• What identifier it used
• What response came back
• Whether it will retry
• Whether it ultimately succeeded

Use correlation IDs

One identifier that travels through the workflow can reduce hours of searching. Microsoft’s monitoring guidance recommends propagating unique activity or correlation IDs through services rather than relying on timestamps alone.

Alert on missing activity

An error alert tells you when a system reports a failure.

A missing-activity alert tells you when nothing happened.

For example:

• No leads reached the CRM today
• No bookings were attributed this morning
• No webhook events arrived in the last hour
• No orders synchronized overnight

Silent failures often need both.

Document ownership

For every integration, record:

• Business owner
• Technical owner
• Vendor contacts
• Connected accounts
• Credential owner
• Renewal or expiration dates
• Escalation path

Test the full workflow periodically

A successful API ping does not prove a lead can complete the real journey.

Run a controlled test that reproduces the actual business process.

When an independent technical assessment makes sense

Some integration failures can be solved by one vendor support ticket.

An independent investigation becomes useful when:

• Several vendors are involved
• Nobody has documented the complete workflow
• Each vendor says its component is healthy
• The issue is intermittent
• Logs exist in several platforms
• The business cannot tell where data stops
• Previous fixes have not lasted
• The failure has significant operational or financial impact
• You need a solution that does not begin with replacing one vendor’s product

Kismet’s Technical Website Assessment is designed for problems like these. We map the systems involved, review the evidence available at each step, identify the most likely failure point, and document a practical path forward. The assessment is separate from implementation, so the recommendation does not depend on selling a particular platform or rebuild.

That separation is important when several vendors are already defending their own tools.

The first goal should be understanding what happened.

Once the failure is supported by evidence, deciding who should fix it becomes much easier.

—

Still unsure which path makes sense?

A Technical Website Assessment can identify the source of the problem, document the available options, and give you a practical implementation roadmap.

Request a Technical Assessment

—

Written by Joey Zuccarini
COO at Kismet Creative Co.