CRM & API / 02
Website CRM integration: how to avoid lost and duplicate leads
The form says “Sent”, but no deal appears in the CRM. Or a customer clicks twice and two managers receive the same enquiry. A website CRM integration needs a traceable journey from submission to the responsible person, including failures and retries.
Key takeaway
Accepting a form and creating a CRM deal are separate events. Save the request before confirming receipt, track delivery and decide how retries should work.
1. Agree on a data contract before connecting the API
Create a field map with each value's source, format, required status and CRM destination. Typical fields include contact details, message, service, language and source page. Avoid collecting extra data simply because the CRM has space for it.
Separate the contact from the enquiry. The same customer may have two different requests; a matching email does not automatically mean a duplicate deal. Contact matching and submission deduplication need separate rules. Also decide whether a public form is allowed to overwrite an existing customer's name or phone number.
| Field | Purpose | Rule |
|---|---|---|
| request_id | Request identifier | Keep it stable during a technical retry |
| email / phone | Customer contact | Validate on the server |
| service / message | Enquiry context | Preserve it when creating the deal |
| language / source | Routing | Accept only permitted values |
2. Design a dependable delivery path
When losing an enquiry is unacceptable, a useful flow is: browser → website server → saved request → CRM delivery → stored external identifier. Confirm receipt only after durable storage. A temporary CRM outage should not force the customer to refill an already accepted form.
In a small system, a table with processing states and a separate worker can act as a queue. More demanding workloads may justify a dedicated queue service. What matters is distinguishing received, pending, delivered and needs-attention states. Failure to save in your own storage must produce a clear error, never a false success message.
3. Handle duplicates and uncertain responses
Idempotency means repeating the same operation does not produce another result. Use a stable request identifier and server-side checks for retries. Disabling the submit button helps the interface but does not protect against network retries or concurrent processing.
A more difficult case occurs when the CRM creates a deal but its response is lost. Retrying blindly may create another deal. Use an idempotency key if the API supports one; otherwise investigate lookup by external identifier and a reconciliation procedure. Check the specific CRM's capabilities before promising exactly-once processing.
Check webhook delivery rules too. Stripe, for example, documents possible duplicate events and does not guarantee delivery order. This illustrates an external API contract; it does not establish the behaviour of every CRM, whose own documentation must be checked.
4. Distinguish temporary and persistent failures
A timeout or temporary outage may allow a delayed retry. A field-format error needs corrected data. An expired credential requires an owner's attention. Retrying every failure in the same way indefinitely hides problems and adds unnecessary load.
Limit automatic attempts, respect documented API limits and keep a safe record of the last failure. Provide a review list for requests that could not be delivered. Watch the age of the oldest pending request as well as error counts: a queue can grow while individual endpoints appear healthy.
5. Limit credentials and log contents
Keep secret CRM credentials on the server. Grant the integration only the permissions it needs, separate testing from production and define how keys will be rotated. Verify incoming notifications using the provider's documented method; a hard-to-guess endpoint alone is not sufficient evidence of the sender.
Operational logs usually need a request identifier, timestamp, status and safe error code. Avoid uncontrolled copying of customer messages and tokens into logs. Agree on data retention and access with the person responsible for data handling in the company.
6. Test the whole workflow before launch
Go beyond checking that a deal appears in a test CRM. Verify its owner, language, service, notification and link to the original enquiry. For each test, write down the expected outcome and how it can be observed.
Handover should include the field and status definitions, a configuration inventory without secrets, a retry procedure and a maintenance owner. If two-way synchronisation is needed, define which system owns each field and how conflicting updates are resolved.
- A normal submission creates the expected fields and owner.
- Repeating one request does not create a second deal.
- A new enquiry from the same customer remains a separate request.
- An accepted request remains recoverable during a CRM outage.
- A lost CRM response is reconciled before creating a duplicate.
- Invalid data and expired credentials are visible to the owner.
- The queue recovers after an outage and results can be reconciled.
Common questions
- Can the browser send data directly to the CRM?
- Some providers offer a public API for that purpose, but secret credentials must never be placed in the browser. Server-side intake gives you a central place to validate data, manage retries and track delivery.
- When is an existing plugin enough?
- When it supports your fields, is compatible with your website and CRM versions, exposes failures and can recover failed deliveries. Validate those properties with test requests before launch.
- Is two-way synchronisation necessary?
- No. Sending website enquiries to the CRM often needs only one direction. Reverse synchronisation is needed when the website displays customer statuses or other data maintained in the CRM.
Apply this to your project
Tell us how your website is built, which CRM you use and what should happen after a submission. We can define the integration flow and its launch checks.
Discuss your projectRelated service: Backend development and API integrations