Website Integrations: Connecting Your Site to CRM, Payments, Email, Accounting

The short answer

Website integrations connect what happens on your site (a form, a booking, a payment) to the systems your business runs on: CRM, payment processor, email platform, calendar and accounting. Most connections are standard and come built into the tools; some need a middleware platform; a few need custom code. The failures are predictable: duplicate records, events arriving out of order, rate limits, polling delays, expiring credentials and field mappings that drift. Design for those five and most integrations run for years without attention.

The five website integrations almost every business needs

Each of these moves one piece of information from the website into a system of record, and each has a standard version and a custom version.

Integration	What moves	Standard (built in)	Custom (needs code)
CRM	Form submissions become contacts and deals	Form embed or native plugin from the CRM	Lead scoring, routing by territory, de-duplication against existing records
Payments	Checkout, deposits, invoices, subscriptions	Hosted checkout, payment links	Order fulfilment triggered by payment, partial refunds, usage-based billing
Email marketing	Consent and list membership	Native sign-up form	Segments based on behaviour, consent records synced from the CRM
Calendar	Bookings and availability	Booking tool embed with one-way sync	Two-way sync across staff calendars, resources, travel time
Accounting	Invoices, payments, customers	Payment processor's accounting connector	Multi-entity, deferred revenue, matching payments to invoices with fees split out

The rule of thumb: if the vendor on either end has built the connection, use it. Native integrations are maintained by people whose job depends on them working. Custom code is for the cases the vendors did not anticipate, which are usually the cases that make your business yours.

Three ways to connect: native, middleware, custom

• Native. The vendor built it; you switch it on. Fast, cheap, reliable, and limited to exactly what the vendor imagined.
• Middleware. Platforms such as Zapier connect apps without code by watching for triggers and running actions. Two things to understand about them: they usually poll rather than listen, and you pay per task. Zapier's published plans, as of October 2026, poll every 15 minutes on the free plan (100 tasks a month), every 2 minutes on Professional (from US$19.99 a month for 750 tasks, annual billing) and every minute on Team (from US$69 for 2,000 tasks). A new lead can therefore sit unseen for up to 15 minutes on the free plan, which matters when, as we argue in our piece on speed to lead, the first business to reply tends to win.
• Custom. Code you own that receives events from one system and writes to another, hosted on your infrastructure or a serverless function. Highest control, highest upfront cost, and the only route when volume, speed or logic exceed what middleware handles. Our comparison of Zapier, Make, n8n and custom code gives the break-even.

How website integrations actually work: APIs and webhooks

Two mechanisms underlie everything. An API is a door a system opens so that other software can read or write its data on request: "give me this contact", "create this invoice". A webhook is the reverse: the system calls you when something happens, sending a small message to a URL you control: "a payment just succeeded".

A typical payment integration shows both at work. A customer pays through hosted checkout. The processor sends a webhook to your endpoint saying the payment succeeded. Your endpoint verifies the message came from the processor, records the event, immediately replies "received", and hands the work to a queue. A worker then calls the CRM API to mark the deal won, the accounting API to create the paid invoice, and the email API to trigger the receipt and onboarding sequence.

Stripe's webhook documentation spells out the behaviours you must design around, and other providers behave similarly. Your endpoint must "quickly return a successful status code (2xx) before any complex logic that might cause a timeout." Stripe retries failed deliveries "for up to three days with an exponential back off." It "doesn't guarantee the delivery of events in the order that they're generated." And endpoints "might occasionally receive the same event more than once," so you should log processed event IDs and skip repeats. Every one of the failure points below traces back to ignoring one of those sentences.

Seven common failure points, and how to design around them

1. Duplicates. The same webhook arrives twice, or a middleware task re-runs, and the customer gets two invoices. Fix: treat every event ID as processed-once, and make writes idempotent, so running them twice produces the same result.
2. Out-of-order events. "Subscription cancelled" arrives before "subscription created", and your CRM ends up showing an active customer. Fix: never trust event order; on each event, fetch the object's current state from the API and write that.
3. Rate limits. A bulk import or a busy afternoon hits the API's ceiling and requests start failing. HubSpot's published limits, for example, allow private apps 100 requests per 10 seconds and 250,000 per day on Free and Starter tiers, returning an HTTP 429 error once exceeded. Fix: queue writes, back off and retry on 429, and batch where the API allows.
4. Polling delay and missed events. Middleware checks every 15 minutes, so a lead waits; or a polling trigger misses records created during an outage. Fix: use webhooks (instant triggers) wherever the source supports them, and reconcile nightly by comparing counts on both sides.
5. Expiring credentials and channels. OAuth tokens expire, API keys get rotated by a departing employee, and some subscriptions simply lapse: Google's Calendar API notes that notification channels expire and that "there's no automatic way to renew a notification channel," per its push notifications documentation. Fix: store credentials centrally, alert on authentication failures, and schedule renewals before expiry.
6. Field mapping drift. Someone renames a CRM property or adds a required field, and every sync starts failing silently. Fix: map by internal IDs, not display names; validate payloads; alert on schema errors rather than swallowing them.
7. Nobody is watching. The integration fails on a Friday and is noticed the following Thursday. Fix: a dead-letter queue for failed events, a daily summary of volumes, and an alert when volume drops to zero, which is the most common symptom of a broken connection.

Consent, privacy and the data you pass around

Integrations move personal information, so they inherit your privacy obligations. Three habits keep them clean. Pass only the fields the destination needs; the accounting system does not need the lead's marketing preferences. Record consent where it is given (the form) and sync the consent record, with a timestamp and the wording shown, to the email platform; in Canada, commercial email needs consent that satisfies CASL, and the integration is where that proof is either preserved or lost. And know where each system stores its data, because the moment you connect a Canadian CRM to a US email tool, the data crosses a border.

Payments deserve one extra note: never let card details touch your own systems. Hosted checkout and payment links keep the card data with the processor, which keeps you out of most of the compliance burden. For Canadian businesses, Stripe's published domestic rate is 2.9% plus CA$0.30 per successful card transaction as of October 2026, with 0.8% added for international cards and 2% for currency conversion.

What to ask before you pay for an integration

• Which direction does data flow, and which system is the source of truth for each field?
• How quickly must it happen: within seconds (lead response), minutes (bookings) or by tomorrow (accounting)?
• What happens when it fails: does it retry, who is alerted, and how do we replay missed events?
• Who owns the credentials, and what happens when that person leaves?
• How is it tested before launch, and how will we know it is still working in six months?
• What does it cost each month in middleware tasks, API tiers and maintenance, not only to build?

A builder who answers those six without hesitation has done this before. When we scope API integration or CRM integration work, the monitoring and the failure handling are part of the fixed price, because an integration without them is a liability with a launch date.

Key takeaways

• Use native integrations where they exist, middleware for low-volume connections, and custom code for the one flow where speed or logic matters.
• Webhooks are delivered at least once, possibly out of order, and retried for days; reply fast, de-duplicate by event ID and fetch current state.
• Respect rate limits with queues and back-off; alert on authentication failures and on volume dropping to zero.
• Pass only the data each system needs, and sync consent records with timestamps.
• Insist that monitoring and failure handling are in the quote.

Frequently asked questions

What is the difference between an API and a webhook?

An API lets your software ask another system for data or send it changes on request. A webhook is the other system calling you when something happens, sending a message to a URL you control. Reliable integrations use webhooks to learn that something changed and the API to fetch the current, authoritative state.

Do I need a developer to integrate my website with my CRM?

Not for the basics. Most CRMs offer a native form embed or plugin, and middleware such as Zapier covers many simple flows without code. You need a developer when speed matters (lead response in seconds), when volume approaches API or task limits, or when the logic (routing, de-duplication, multi-step fulfilment) exceeds what middleware can express.

Why does my integration create duplicate records?

Usually because the source delivers the same event more than once (webhooks are retried until acknowledged) or a middleware task re-ran after a timeout, and the destination has no check for existing records. Log processed event IDs, match on a unique key such as email or order number before creating, and make writes idempotent.

Sources

1. Receive Stripe events in your webhook endpoint — Stripe Documentation, accessed October 2026
2. Zapier plans and pricing — Zapier, accessed October 2026
3. API usage guidelines and limits — HubSpot Developers, accessed October 2026
4. Push notifications — Google Calendar API documentation, accessed October 2026
5. Pricing and fees — Stripe Canada, accessed October 2026

How Flowmatix can help

We put this into practice for businesses in Toronto and around the world through our API Development & Integration, crm development & integration, web development services. Want to know what it would take for your business? Get a personalised quote in about 3 minutes.