Integrating your website with CRM, ERP and accounting systems

Connecting your website to a CRM, ERP or accounting platform means moving data through APIs, usually webhooks that push events the moment they happen, backed by scheduled polling to catch anything a webhook missed. The integrations that last are treated as products in their own right: fields mapped deliberately, failures handled by design, and every account owned by the business rather than its vendor. Here are the decisions that matter before anyone writes a line of code.

Why connect your website to your CRM, ERP or accounting system?

Most websites already collect the data your back office runs on. A contact form captures a lead. A checkout creates an order. A booking widget commits staff time. Without integration, someone re-keys all of it: copying form submissions into a CRM such as HubSpot or Salesforce, raising invoices in QuickBooks or a similar accounting package by hand, and updating inventory in the ERP after the fact.

Re-keying is slow, but that is the least of it. It introduces transcription errors, it delays follow-up on new leads until someone gets to the inbox, and it means the website and the system of record disagree until a person catches up. An API-first integration removes the human relay: the website talks to the platform's documented API directly, so a submitted form becomes a CRM contact in near real time, an order becomes a draft invoice automatically, and stock levels on the site reflect what the warehouse actually holds. The gains are qualitative but real: faster response to enquiries, cleaner data, and staff time spent on judgement rather than copying.

"API-first" matters as a filter when you choose platforms, too. The established CRM and accounting platforms publish REST APIs, sandbox environments and webhook systems, though the specifics change often enough that you should design against their current documentation rather than any summary of it. If a platform you are evaluating treats its API as an afterthought, expect every future integration to be harder than it should be.

Webhooks or polling: which should you use?

There are two basic ways to keep systems in sync. A webhook is a push: the platform calls a URL on your server the moment something happens, when a deal changes stage, an invoice is paid or a contact unsubscribes. Polling is a pull: your system asks the API on a schedule, "what changed since I last looked?" and processes the answer.

Webhooks feel obviously better, and for freshness they are. But providers generally deliver webhooks on a best-effort basis: if your endpoint is down during a deploy, or the provider has a bad afternoon, events can be dropped and never re-sent. Polling never misses anything the API can report, but it burns requests, runs into rate limits, and is only as current as its schedule.

Our default recommendation is the hybrid: webhooks for speed, plus a scheduled reconciliation job, hourly or nightly depending on the data, that compares the two systems and repairs anything the webhooks missed. It is the difference between an integration that is usually right and one you can stop thinking about.

How do you get field mapping right?

Field mapping sounds like a technical chore. It is actually where most integrations quietly go wrong, because it forces questions the business has never had to answer precisely.

1. Name the source of truth for every field. If a customer's email lives on the website account, in the CRM and in the accounting platform, which one wins when they disagree? Decide per field, in writing, before development starts, and make sure your own data model reflects that decision.
2. Set the direction of sync. Some fields flow one way (website form to CRM), some flow back (deal stage to a customer portal), and a few genuinely need two-way sync. Two-way is the hardest to get right, so use it only where it earns its complexity.
3. Normalise formats at the boundary. Phone numbers, provinces, postal codes, tax codes and currency all have canonical formats in each platform. A Canadian address that stores "British Columbia" on the website and expects "BC" in the ERP will fail validation somewhere, eventually.
4. Reconcile picklists and required fields. If the CRM requires a lead source and the website never asks for one, the integration must supply a sensible default, and someone should agree on what that default says about the data.
5. Write the map down. A simple table of source field, destination field, direction, transformation and owner becomes the single most-consulted document in the project, and the first thing anyone checks when a record looks wrong.

How should the integration handle failure?

Every integration fails sometimes. APIs go down, rate limits trigger, credentials expire, a provider ships a breaking change. The design question is never whether failures happen but what your system does next.

An integration that fails silently is worse than no integration at all, because people trust the data, and the data is wrong.

Four patterns cover most of it. First, retries with backoff: transient errors should be retried automatically, with increasing delays so you do not hammer a struggling API. Second, idempotency: every operation should be safe to run twice, so a retry creates one invoice rather than two, usually by keying records on a stable external ID instead of plain "create new" calls. Third, a dead-letter queue: events that still fail after retries land somewhere a human can inspect and replay, instead of vanishing. Fourth, alerting: when the queue grows or an endpoint has been failing for more than a few minutes, a person finds out through a channel they actually read.

Add plain logging, what was sent, what came back and when, along with version awareness, because CRM and accounting APIs retire old versions on published schedules and an unwatched integration will eventually stop working on a date the provider announced well in advance.

Who should own the integration accounts and API keys?

This is the part almost nobody discusses up front and everybody regrets later. Integrations run on credentials: OAuth app registrations, API keys, service accounts, middleware subscriptions. If those live in a developer's personal login or an agency's account, the business has a dependency it cannot see until the relationship ends, and then the integration stops working the day access is revoked.

The fix is straightforward. Every app registration and API key is created inside the client's own admin console, under an account the client controls. Credentials are scoped to the minimum access the integration needs, stored in a secrets manager rather than in code, and rotated when people leave. Sandbox and production credentials stay separate. Our approach to security and compliance treats credential ownership as part of the architecture rather than an afterthought, and at OlDevs, clients own all code, designs, accounts and IP as a matter of policy, so there is nothing to hand over because it was yours from the start.

Should you build a custom integration or use middleware?

Middleware platforms in the Zapier and Make category connect popular tools with little or no code, and for simple, low-volume flows they are a perfectly good answer: a form submission that creates a CRM contact does not need custom engineering.

Middleware strains when the work gets serious. Multi-step logic with branching and lookups becomes hard to read and harder to test. Pricing on these platforms is typically tied to how much they run, so cost follows volume upward. Error handling is often shallow: a failed step frequently just stops. And when the data includes payment, health or other regulated information, routing it through a third party raises compliance questions that need real answers.

Custom integration, a small service your team owns, built and tested like any other piece of software, makes sense when the flow is core to how the business operates, when volume is meaningful, or when failure has a cost. It is a natural fit within a broader web application build, where the integration layer is designed, versioned and monitored alongside the product it serves.

How OlDevs approaches integration work

OlDevs is a full-stack technology studio in Vancouver, building web and mobile products since 2014. Integration projects here follow the same discipline as everything else we ship: one accountable team, a working demo every week so you can see data flowing before launch, and WCAG 2.2 AA accessibility on every interface we touch. We map fields with your team before we write code, build the hybrid webhook-plus-reconciliation pattern by default, and set up alerting so problems surface to people, not log files. You can read more about how we work. Wherever you are, we work with you remotely, with video calls in your time zone and on-site visits when the work calls for it.

If your website and your CRM, ERP or accounting platform are still connected by copy and paste, we can fix that. Request a quote and we will reply within one business day.