Website Integration for Business Sites: How to Connect CRM, ERP and Chatbots

Website integration decides whether your site acts as a shop window or as a working part of the business. In this guide I walk through the architecture behind it: APIs, webhooks, middleware, ERP stock and price sync, chatbot handoff and security. In short, you will know which system owns which data, and how that data should travel.

What is website integration for a business website?

Website integration is the automatic exchange of data between your business website and systems such as a CRM, an ERP or a chatbot platform, through APIs, webhooks or middleware. The goal is simple: nobody types the same data twice, and stock, prices and customer records come from one trusted source.

I have worked on corporate projects since 2012, and the starting picture rarely changes. The website lives in one place, the accounting or ERP software in another, and the sales team keeps its own spreadsheets. However, customers never see that split. They expect the price on the page, the stock status and the words of your sales rep to match.

This article is not a step by step guide on sending form data into a CRM. I cover the form itself in my lead form design guide. Here we look at the wider picture: how the systems connect, and who owns what.

Which systems should connect to your website, and why?

Every company has its own system map. Still, these are the connections I meet most often on business sites:

• CRM: owns contacts, deals and tasks. The site sends new contacts and requests here.
• ERP: owns products, stock, prices, customer accounts and orders. The site reads from it and writes orders to it.
• Chatbot or live chat: handles the first conversation and hands over to a human when needed.
• Email marketing tool: holds newsletter lists and automated sequences.
• Payment and shipping providers: report payment status and delivery events.

Why bother with website integration at all? Because manual copying is slow and error prone. For example, a manufacturer that updates its price list on the site once a month will quote wrong prices in the week the exchange rate moves. Worse, the customer usually spots the mistake first.

What does "single source of truth" mean in practice?

Every type of data needs exactly one owner. If the ERP owns stock, nobody edits stock on the website. If the CRM owns contact details, the ERP copy takes its updates from the CRM. I ask clients to write this down in a table on day one.

Website integration projects that skip this step run into two way conflicts. A customer changes a phone number on the site, the ERP keeps the old one, and the nightly sync then writes the old number back. So the question "who writes, who reads" is a management decision, not a technical detail.

API, webhook or middleware: what is the difference?

These three terms get mixed up a lot, so let me separate them. An API is a door a system opens to the outside; you ask, it answers. A webhook works the other way around: when something happens, the system tells you. Middleware sits between the doors. It translates the data, routes it and keeps a log.

Also check what the other system offers. Some CRMs have rich webhook support, while some older ERPs only expose a query API. In other words, the connected system often picks the method for you. Your job is to build a solid flow around that limit.

In practice, most business projects mix all of these. For instance, the catalogue syncs overnight through an API, payment confirmations arrive by webhook, and CRM traffic passes through middleware.

Point to point or a central integration layer?

With two systems, a direct connection works fine: the site talks straight to the CRM API. However, the number of links grows quickly as you add systems. Connect four systems directly to each other and you end up maintaining six separate bridges, each with its own error handling.

With a central layer, each system connects only to the middle. So when you replace the CRM, you leave the website code alone and swap one connector instead. My rule of thumb:

• Two systems and low volume: direct API calls, simple code.
• Three or more systems: a central layer with one monitoring screen.
• Heavy business rules such as dealer pricing or discount matrices: your own service.

Large teams that plan to split the front end into parts should also read my piece on micro frontends in enterprise architecture. Keeping the integration layer apart from the user interface is a core rule there too.

When does an iPaaS tool make sense?

iPaaS stands for Integration Platform as a Service. The term covers cloud tools that link systems through ready made connectors with little or no code. Zapier, Make and n8n are the names I see most often with smaller companies. Larger firms tend to use heavier enterprise platforms.

These tools save time. Moreover, business teams can build simple flows without waiting for a developer. On the other hand, discuss three risks up front:

• Cost: most tools charge per task or operation, so the bill grows with volume.
• Invisible flows: automations that nobody documents tend to stop quietly one day.
• Data location: personal data now passes through a third party, so your contracts and privacy notice must reflect it.

Here is a rough line from my own field experience, not a guarantee. If you have only a handful of flows and low volume, iPaaS is a good start. Once the flows fill up with business rules, plan a move to your own service.

How do you set up ERP stock and price sync?

The first question in any ERP link is which fields move, how often, and in which direction. I start by reading a product record in the ERP line by line. Then I map the item code, unit, tax rate, list price and any dealer price one by one.

Next, we decide the sync frequency. Catalogue text can often update once a day. Stock depends on how fast products sell. For slow moving industrial goods, an hourly update usually does the job. For fast selling ecommerce products, you need near real time events.

1. Build a field mapping table: ERP field, site field, transformation rule.
2. Run the first full import in a test environment and compare 50 random products by hand.
3. Switch to delta sync so that only changed records move.
4. Log the start, end and error count of every run.
5. Decide who receives an alert when a sync stops.

I cover dealer and export scenarios in my article on website design for manufacturers. That piece also looks at who should see which price.

What should you watch when writing orders into the ERP?

Reading is easy; writing is risky. Once your site writes orders into the ERP, it touches accounting records, so the margin for error should be close to zero.

The first rule is idempotency. When the network drops, the site may try to send the same order twice. Therefore give every order a unique key and let the ERP side reject a second record with the same key. The second rule is stock reservation: hold the stock while payment is pending, but only deduct it for good after confirmation.

Third comes customer account matching. When a new buyer arrives, do you open a new account in the ERP, or look up an existing one by tax number? Make that call together with your finance team. Finally, plan cancellations and returns. Many projects build only the happy path and leave cancellations to manual work.

How should the CRM side of the architecture look?

The architectural question on the CRM side is this: does the site write straight into the CRM, or through a queue? Direct writes are simple. However, if the CRM goes offline for a few minutes, the requests from that window can vanish.

That is why I place a small queue between the site and the CRM on business projects. The site first saves the request in its own database. Then the queue sends it on. If the CRM does not answer, the queue retries a few times. If it still fails, the record lands on an error list and the owner gets a notification. As a result, no request disappears silently.

Field mapping, source tracking and lead routing rules sit outside the scope of this article. For clean campaign tags, the UTM builder helps. From an architecture view, remember one thing: you should be able to trace every record in the CRM back to its source, even without the website.

How does chatbot handoff to a human work?

A chatbot proves its value at the moment it cannot answer. In a good handoff, the bot passes three things to the human agent: a summary of the conversation, the visitor's contact details if they gave consent, and the page they came from.

Define the triggers clearly. For example, the bot should hand over when the visitor types "agent" or "human", when it fails to understand twice in a row, or when the topic is a complaint or a price negotiation. Outside office hours, the bot should say so honestly and create a callback request.

• At handoff, the CRM opens a task and attaches the chat summary.
• Until an agent replies, the visitor sees an estimated wait time.
• The bot answers stock and price questions with live ERP data, never with guesses.

That last point matters. A chatbot quoting a wrong price does more damage than a wrong price on a product page, because the visitor takes it as a personal promise.

Which data should a chatbot access, and which not?

Once you connect a chatbot to the ERP and CRM, you give it something like employee access. So start with the narrowest rights possible. General product information, stock status and list prices are usually fine. By contrast, customer specific discounts, account balances or another person's order status should never reach the bot without separate verification.

A practical approach: connect the bot through its own read only integration user. If a visitor asks about an order, the bot first matches two details, such as order number and email. Then it shows the status of that one order only. That way the bot helps without turning into a data leak.

In addition, the bot should have no write access to the ERP. If a quote or order request comes in, the bot opens a CRM task and a human approves the next step. Put simply, the bot greets people at the door; it never touches the till.

How do you keep website integration secure?

Integration wires your website into the core of your business systems, so security deserves its own section. OWASP collects API specific risks in the OWASP API Security Top 10. Broken object level authorisation sits at the top of that list. In plain words: a user sees someone else's order simply by changing the ID in a request.

These are the minimum rules I apply on projects:

• A separate, narrowly scoped user or app key for every integration.
• Keys stored in server environment variables or a secrets vault, never in code.
• Signature checks on every incoming webhook; reject anything unsigned.
• HTTPS for all traffic, and ERP access only from approved IP addresses.
• Regular key rotation, with old keys revoked.

The password generator helps you create strong secrets. On the authorisation side, many modern APIs rely on the OAuth 2.0 framework, so make sure your team understands that flow.

Why do webhooks sometimes arrive twice?

This question surprises almost every team building its first website integration. When the receiving side does not confirm quickly, the sending system retries. The Stripe webhook documentation, for instance, states clearly that the same event can arrive more than once and that you should ignore duplicates by event ID.

So build three habits on the receiving side. First, log the ID of every event and skip any ID you have already handled. Second, reply "received" fast and do the heavy work in the background. Third, never assume events arrive in order; a "cancelled" event can land before a "created" one.

Skip these details and you get the usual symptoms: double invoices, double emails or wrong stock. In other words, the problem sits in the assumption, not in the code.

Does integration slow down your website?

Built well, website integration does not. Built badly, it can hurt a lot. The most common mistake is a live ERP query on every page load. When the ERP answers slowly, the product page slows down too, and the ERP carries load it never needed.

Instead, sync the data into the site's own database or cache and serve pages from there. Keep live queries for the moments that truly need them, such as a final stock check when someone adds an item to the cart. As a result, visitors get fast pages and the ERP can breathe.

Chat widgets and tracking scripts add weight as well. Load them after the main content. I explain how speed affects search visibility in how site speed affects SEO.

Who hears about it when something breaks?

The most dangerous website integration is not one that fails, but one that fails silently. A sync stops for three days, nobody notices, and then a customer buys a product that is out of stock.

That is why every project gets a simple monitoring setup:

1. A "last successful run" timestamp for every flow.
2. An email or chat alert once the expected interval passes.
3. An error list where the team can see failed records and retry them with one click.
4. A short weekly summary: how many records moved, how many failed.

Who receives the alert sounds like a detail. It is not. When stock sync stops, operations should know. When the CRM flow stops, the sales manager should know. In short, carry your ownership table over to monitoring as well.

How should you document a website integration?

When the person who built an integration leaves, only the documentation stays behind. So I ask for a short but complete integration file on every project. Not a book; rather a summary a new team member can read and understand in one afternoon. Store it in a shared folder, not on someone's laptop.

• System map: which system connects to which, and how.
• Data ownership table: the owner of every field and the flow direction.
• Field mapping list and transformation rules for currency, units and tax.
• Where the keys live (the location, never the key itself) and the rotation schedule.
• Failure scenarios, plus who does what in each case.
• Change history: who changed what, and when.

Keep the file alive. An update takes five minutes after each change. Skipping it costs hours during the next outage. Put simply, documentation is the insurance policy of any integration.

Who should own the integration inside the company?

A developer or an agency builds the integration. Still, the business owner must sit inside the company. Otherwise every incident turns into finger pointing: the agency blames the ERP, the ERP vendor blames the website, and sales blames "the system".

I usually define two roles. First, the business owner, often the operations or sales manager, who decides which data flows where. Second, the technical owner, someone in IT or a contracted support partner, who receives alerts and handles first response.

Put both names on the first page of the documentation. Moreover, have them review the flows together once a year. Business processes change, and the integration has to change with them.

What if your ERP has no API?

I meet this often with local accounting and ERP packages. Not every product offers a modern web API. Some provide only database access, file exports or a paid add on module.

Weigh the options in an order that protects security. First, ask the vendor whether an official integration module exists. Next, consider a file based exchange: the ERP exports a file on a schedule and your integration service reads it. The last resort is a read only, restricted user on the ERP database.

Avoid writing straight into the ERP database. It bypasses the vendor's business rules, may break after an update and can void your support terms. In short, always use the official route for writes.

What drives the cost of an integration project?

I will not quote a figure here, because the cost depends entirely on scope. However, I can list the items to compare between proposals:

• The number of systems and the quality of each API.
• Flow direction: read only, or writes as well?
• The complexity of business rules such as dealer pricing, promotions or multiple warehouses.
• Middleware licences or monthly iPaaS fees.
• Extra modules or user licences on the ERP or CRM side.
• Responsibility for monitoring, maintenance and version upgrades.

Teams forget the last item most often. When the CRM or ERP upgrades, the integration may need an update too. So confirm in writing whether your maintenance contract covers it. To set a measurable target for the project, read my guide on setting website conversion goals.

How do you measure whether the integration pays off?

Website integration is a tool, not a goal. Therefore judge it with business metrics rather than technical ones. Before you start, pick three or four measures and record today's values. Otherwise, six months later you will answer "did it work?" with gut feeling alone.

• Speed to lead: how many minutes from form to sales rep?
• Stock related cancellations: how many orders per month fail with "out of stock"?
• Manual data entry: how many hours per week does the team spend copying and pasting?
• Price mismatch complaints: how often did the site price differ from the invoice?

Measure before and after with the same method. For example, pull cancellations from the ERP report and response time from CRM timestamps. Then you see the return in concrete terms, and if nothing improves, you know which flow to revisit.

Should you build an integration without a test environment?

You can, but I would not. Testing on a live ERP means writing fake orders into real customer accounts, and your finance team then cleans them up one by one. Also, one wrong bulk update can break an entire price list within minutes.

So ask your ERP and CRM vendors about a sandbox at the start. Many cloud CRMs offer one. With local ERPs, you can often create a separate test company from a copy of the database. Keep test data realistic, but mask personal data.

Once it exists, a test environment serves every future change, not just the first project. Think of it as long term insurance rather than a one off cost. If you want help mapping this out, the web design service page explains how I plan integration points from the start.

What should you test before going live?

My pre launch website integration test list is short, and I do not compromise on it:

• Happy path: a normal order, a normal request, a normal stock update.
• Outage: does a request survive while the CRM or ERP is offline?
• Duplicates: does the same webhook twice create two records?
• Edge data: special characters, very long addresses, empty fields, other currencies.
• Access: can one user see another user's order?
• Rollback: can you switch the integration off and return to manual work?

I stress the last item. Every integration needs a kill switch. Then, when an error appears at midnight, you stop the flow without taking the site down. For ecommerce setups with marketplaces and payment providers, my ecommerce consulting work covers each channel. You can also check DNS records with the DNS lookup tool, or reach me through the contact page.