Integrating your website with your CRM and ERP: patterns that work

Connect a website to a CRM or ERP by deciding which system owns each piece of data, then moving it with events and a queue rather than direct calls. Use a native connector for simple form-to-CRM flows. Build a small integration service when orders, stock or invoices are involved, so a slow back-office system never breaks the website.

Why integrate the website at all?

Because the website is where most enquiries and many orders start, and every one that gets retyped is a delay and a chance of error. The symptoms are familiar: a sales team copying form emails into the CRM, an office manager keying web orders into the accounts package, stock levels on the site that disagree with the warehouse. Our guide to business process automation for UK SMEs lists data sync between systems as one of the ten processes worth automating first, and this is usually where it starts.

It is also the classic case for building only a thin layer. You buy the CRM and the ERP; what you commission is the connection between them and the site. That is the "buy the systems, build the glue" answer from our build vs buy guide.

Which system should own each piece of data?

Decide this before anyone writes code, field by field. In our view, most integration problems come from two systems both believing they own the same thing. A typical split for a small business:

Data	Usual owner	What the website does with it
Leads, contacts, consent	CRM	Creates or updates them from forms
Products, prices, stock	ERP or inventory system	Reads them, usually from a cached copy
Orders	Website first, then ERP	Captures the order, hands it on
Invoices and payments	ERP or accounts package	Shows status; never edits
Sessions, baskets, logins	Website	Keeps them to itself

The rule that follows from the table: one owner per field, and every other system holds a copy it does not edit. If the sales team can change a customer's address in the CRM and the accounts team can change it in the ERP, you have a reconciliation job, not an integration.

What are the main integration patterns?

There are four, and most SME projects use two of them.

1. Native connector or vendor form. HubSpot, Zoho, Pipedrive and most other CRMs offer embeddable forms or plugins for common website platforms. The submission goes straight into the CRM. This is the right answer for "website enquiries should land in the CRM" and costs little to maintain. It stops being enough when you need your own rules: deduplication, routing to different pipelines, or passing the same data to an ERP.

2. Integration platform (iPaaS). Zapier, Make and Power Automate connect systems with configured steps rather than code. Good for low volumes and simple mappings, and a sensible way to prove a flow before paying for a build. The weak points are error handling and visibility: a failed step can go unnoticed until someone asks where an order went.

3. Events plus a queue. The website records what happened (an enquiry, an order, a payment), answers the visitor immediately, and puts a message on a queue. A small service reads the queue and calls the CRM or ERP API at a pace it can sustain, retrying when it fails. This is the pattern for anything involving money or stock, and it is what we build on a custom web app or a Next.js business website.

4. Scheduled batch sync. A job runs every few minutes or every night and copies changes across. Simple and predictable, and fine for catalogue data that changes slowly. Wrong for anything a customer is waiting on, such as order confirmation or live stock.

Why shouldn't the website call the ERP directly?

Because the ERP will sometimes be slow, busy or down, and the visitor should not pay for that. Microsoft's operational limits for Dynamics 365 Business Central (Microsoft Learn, updated December 2025) are a useful illustration: OData requests are limited per user to 5 processed at once and 6,000 in a five-minute sliding window, and requests over the limit get an HTTP 429 response. An ERP built for the back office is not built to absorb a traffic spike from a sale.

A queue turns that into a non-event. The order is safe in your own database the moment the visitor clicks pay; the hand-off to the ERP happens a few seconds or minutes later, and a failure means a retry, not a lost order.

What do the API rate limits look like?

Smaller than many people assume, which is why batching matters. As of October 2026, from each vendor's developer documentation:

System	Limit	Source
Xero (per connected organisation)	5 concurrent calls, 60 a minute, 1,000 a day on the starter tier and 5,000 on higher tiers	Xero OAuth 2.0 API limits
HubSpot (privately distributed app)	100 requests per 10 seconds on Free and Starter, 190 on Professional and Enterprise; 250,000 to 1,000,000 a day per account by tier	HubSpot usage guidelines
Business Central (per user)	5 concurrent OData requests, 6,000 per five-minute window	Microsoft Learn operational limits

Xero's documentation also notes that several invoices can go in one request and recommends batches of up to about 50. Its advice on hitting a limit is to read the Retry-After header and pause until then. HubSpot's usage guidelines note that the daily limit is shared across every app on the account, so a marketing tool and your integration draw on the same pot.

How do you stop duplicates and lost updates?

Three habits cover most of it.

Make every write safe to repeat. Webhooks get redelivered. Stripe's webhook documentation says endpoints "might occasionally receive the same event more than once", that it retries failed deliveries for up to three days in live mode, and that it does not guarantee events arrive in order. Its advice is to log the event IDs you have processed and skip repeats. Apply the same thinking to your own writes: update-or-create on a stable key (an email address, an order number, the other system's ID), never a blind create.

Answer fast, work later. Stripe tells you to return a 2xx response before any complex logic, giving updating an invoice in your accounting system as the example of work to defer. The same holds for any inbound webhook: acknowledge it, queue it, process it.

Verify what comes in. A webhook endpoint is a public URL that can change your records. Check the provider's signature on every request, and keep the signing secrets in your hosting platform's secret store, not in code.

What about consent and personal data?

The integration moves personal data, so it carries obligations. The practical one for website forms is marketing consent. The ICO's guidance on electronic mail marketing is that you need consent to send marketing emails to individuals, with a limited soft opt-in for existing customers, and that sole traders and some partnerships count as individuals. So the consent tick box, its wording and the date belong on the CRM record, written at the moment the form is submitted. Our guide to UK GDPR and AI for SMEs covers the wider data protection picture. This is general information, not legal advice.

Where should an SME start?

Start with the one flow that causes the most retyping, usually website enquiries into the CRM, and use a native connector for it. Add an integration service only when orders, stock or invoices need to move, and write the ownership table first. Ask any supplier how their design handles the ERP being down for an hour; the answer tells you most of what you need to know.

Frequently asked questions

What is the simplest way to connect a website form to a CRM?

Use the CRM's own form or a native connector for your website platform. The submission goes straight into the CRM with no code of yours in the middle. Move to a custom integration only when you need logic the connector cannot do, such as deduplication rules or routing to an ERP.

Should the website talk to the ERP directly?

Rarely. Put a small service or queue between them. The website saves the order or enquiry, answers the customer straight away, and the service passes it to the ERP at a pace the ERP's API allows, retrying if it is down. A visitor should never wait on, or lose data because of, your back-office system.

How do I stop an integration creating duplicate records?

Give every record a stable key and make each write an update-or-create on that key, rather than a blind create. Log the IDs of events you have already processed and skip repeats, because webhook providers such as Stripe say the same event can arrive more than once.

Do API rate limits matter for a small business?

Yes, more than people expect. As of October 2026 Xero allows 60 calls a minute and 1,000 a day per organisation for apps on its starter tier. A nightly sync that fetches records one by one can hit that. Batch your writes, page your reads and honour the Retry-After header.

Can I send marketing emails to everyone who fills in my website form?

Not automatically. Under PECR, as explained by the ICO, you need consent to email individuals, or the narrow soft opt-in for existing customers. Record the consent with the contact in the CRM at the moment the form is submitted, so the evidence travels with the record.

---

Connecting a site to the systems behind it? See how we build websites and web apps across our web practice, or tell us which systems need to talk.

Easy Insight is a UK consultancy for AI, web, apps and data — senior specialists only, no juniors.