A website-to-CRM connection should do more than copy an email address. It should create a usable record, preserve the customer’s message, route the enquiry to the right person and make failures visible. A fast integration that silently loses leads is worse than a slower manual process.
Choose the system of record for every field
Write a field map before opening either API. For each value, record the website field, CRM field, format, whether it is required and which system is allowed to update it later.
A basic map may include name, email, phone, company, country, service interest, message, consent wording, consent time, landing page and campaign source. Do not collect fields simply because the CRM has them. Every question increases form effort and creates data the team must protect.
Normalise predictable values on the server. Country codes, phone formats and service categories should not rely on whatever text a browser happens to send.
Create the local record before calling the CRM
After validation and anti-spam checks, store the enquiry in the website’s own database with a unique identifier and a status such as pending sync. Then call the CRM. If the external request times out, the customer’s submission still exists and can be retried.
Do not show a success message until the website has safely accepted the enquiry. It is reasonable for CRM synchronisation to finish in the background, provided failures generate an alert and the customer’s message is not lost.
Make retries safe
Networks fail and APIs sometimes return ambiguous results. Send the website’s unique enquiry identifier as an external reference or idempotency key. Before creating a lead, the receiving system should check whether that reference already exists.
Use a limited retry schedule with increasing delays. Record the response status and a safe error message, but do not place secrets or unnecessary personal data in logs. After the retry limit, move the item to a visible failed state for human action.
Define duplicate behaviour deliberately
Email alone is not always a reliable duplicate key. A returning customer may submit a new project request, while two people at one company may share a general address. Decide whether a new submission creates a new lead, adds an activity to an existing contact or reopens an opportunity.
A practical model keeps one contact per person but a separate enquiry or opportunity for each meaningful request. Preserve the original message and timestamp instead of overwriting the previous interaction.
Route the lead using stable rules
Routing can use service, region, customer type or existing account ownership. Keep the initial rules simple and provide a fallback owner. If a category is renamed on the website, the integration should not begin discarding leads because the CRM expects the old label.
Automatic acknowledgements should confirm receipt, set a realistic response expectation and provide a route for urgent or privacy-related requests. They should not pretend that a person has reviewed the message.
Preserve consent and purpose
An enquiry about a service does not automatically create permission for unrelated marketing. Store the wording shown at submission, the choice made, time, source and relevant policy version. Keep operational messages and marketing subscriptions as separate purposes.
Limit CRM access to people who need the data and remove accounts promptly when roles change. Decide how deletion, correction and retention requests move between the website and CRM so the same personal data is not left behind in one system.
Secure both ends
- Keep API secrets on the server, never in browser JavaScript or hidden form fields.
- Use HTTPS and verify signed webhook requests.
- Allow only the fields and event types the receiving endpoint expects.
- Rate-limit public forms and use appropriate spam controls.
- Rotate credentials and document which account owns them.
- Avoid sending full personal records to general-purpose error monitoring.
Test the complete journey
Create a test matrix that includes a normal enquiry, missing required field, international phone number, repeated submission, CRM timeout and declined consent for optional marketing. Check the website response, local record, CRM fields, owner, notification and retry state.
Then run one production test using an address clearly marked as internal. Confirm that the person responsible for enquiries can find it and knows what to do. Remove or exclude the test from sales reporting afterwards.
Monitor the connection after launch
Track accepted submissions, successful syncs, retrying items and permanently failed items. Alert on failure rather than waiting for a salesperson to notice a quiet week. Review field mappings whenever the form, CRM pipeline or consent wording changes.
Sources and further reading
- ICO data protection by design and by default — the source for considering purpose, minimisation and access from the design stage.
- ICO guide to data security — guidance on confidentiality, integrity, availability and recovery of personal data.
Xapner builds server-controlled form, payment and CRM workflows. To discuss an existing integration, send the systems involved and the failure you need to prevent; do not include passwords or API keys in the form.