System Integration for Small Businesses: How to Connect Core Apps

01What is systems integration for a small business?

System integration is the set of rules and connections that lets your core applications share records. A customer created in the CRM appears in QuickBooks with the same billing details. A paid ecommerce order becomes a sales receipt. A booked appointment updates the customer timeline. Without integration, someone copies those records by hand, and the copies drift apart.

An API and an integration are different things. An API is the documented interface a product offers so other software can read or change its data. An integration covers everything built on top of those APIs or files, including which records move, in which direction, on what trigger, how matching works and who fixes a failure. Two companies can use the same QuickBooks API and end up with very different integrations.

For example, a 12-person installation company might take bookings in a scheduling app, track quotes in a CRM, invoice in QuickBooks Online and sell parts through an online store. Each system works well alone. The integration work is deciding how a customer, a job and a payment stay consistent across all four.

02Map the records before you choose a tool

Start with a short written map of what crosses between systems. Tools come later, because the map tells you whether a connector can handle the job at all. Keep the first version to the records your team retypes or reconciles today.

• List each record type that moves between systems, such as customer, contact, product, order, invoice, payment and appointment.
• For each record, write the trigger that should move it, such as order paid, quote accepted or appointment booked.
• Note what should happen when a record is later edited, cancelled, refunded, merged or deleted, because each case needs a rule.
• Count rough monthly volume per record type so you can compare plan limits and API limits later.
• Name the person who will own the integration once it runs and who will check failures.

03Four integration patterns compared

Most small-business integrations use one of four patterns, and many businesses use more than one. A native connector from the vendor's app marketplace is often enough for a common pair like an ecommerce store and an accounting system. An integration platform as a service (iPaaS) such as Zapier, Make or n8n lets you build trigger-and-action workflows without hosting code. A custom API integration is code you own that calls each product's API directly. A scheduled file sync moves CSV or spreadsheet exports on a timetable.

Test the simplest pattern on your real records first. Move to a heavier pattern when the simpler one cannot meet a rule you have written down, such as handling edits, matching on your own IDs or alerting on failures.

04Choose a system of record for each field

Integrations go wrong quickly when two systems both act as the owner of the same value. Pick one system of record per field, and let only that system create or change it. The other systems receive copies. Decide this field by field, because a single customer record usually has parts owned by different systems.

When staff need to change a value in a system that does not own it, give them a route back to the owner, such as a note to accounting or an edit screen that writes to the system of record. Otherwise the next sync overwrites their change, or their change overwrites a correct value.

05Decide sync direction and timing

One-way sync is easier to reason about: the system of record sends changes and the other side accepts them. Use two-way sync only for fields that people legitimately edit in both places, and write the conflict rule before building. A common rule is that the most recent change wins only when timestamps from both systems are reliable. Otherwise the system of record wins and the other change goes to a review list.

For timing, webhooks notify your integration when data changes, and polling asks for changes on a schedule. Intuit's QuickBooks Online webhook guidance, at the time of writing (October 2026), says that events can arrive out of sequence, that the timestamp in the payload is the source of truth for when an event occurred, and that apps should make change data capture (CDC) calls to recover missed events. Intuit documents that CDC looks back over the last 30 days. A reliable integration usually combines both: webhooks for speed and a scheduled catch-up for completeness.

06Store IDs so records match without guessing

Every connected system assigns its own record IDs. Your integration needs a cross-reference that says CRM contact 4512 is QuickBooks customer 87 and store customer 30019. Without it, the integration matches on names or emails, which change, repeat and get mistyped, and duplicates follow.

Some products let you store another system's ID directly. HubSpot's developer documentation, at the time of writing, explains that its record IDs are unique only within an object type, and that you can create custom unique identifier properties, up to ten per object, then use them to retrieve and update records. Intuit says to treat QuickBooks Online entity IDs as strings. Where a product cannot hold a foreign ID, keep the mapping table in your integration's own database.

Use weaker matches, such as name plus postal code, only to suggest a possible link for a person to confirm. Never merge or overwrite on a weak match.

07Make retries safe and failures visible

Networks drop connections, and APIs throttle busy clients. A retry that creates a second invoice is worse than the original failure. Intuit recommends a request ID on QuickBooks Online requests that write, modify or delete data: if the service receives the same request ID again, it can return the original response instead of repeating the operation. Intuit also notes that DocNumber, the visible document number, is not a system-level idempotency key, so query for an existing record before retrying a create that may have succeeded. When QuickBooks Online throttles a request, it returns HTTP 429, and Intuit says to wait 60 seconds before retrying, so your integration should pause and retry instead of failing the batch.

Then make failures someone's job. A sync error that only appears in a log will sit there until a customer complains.

• Send every failed record to an exception list with the source record, the error and the time of the last attempt.
• Alert a named owner when the list grows or a record has waited longer than an agreed time.
• Run a daily reconciliation that compares record counts and totals, such as yesterday's paid orders against yesterday's sales receipts.
• Log request IDs and destination IDs for each write so you can trace what happened without copying sensitive data into logs.
• Write a short runbook for pausing the integration, replaying a failed record and checking the result.

08QuickBooks integration and CRM integration: when custom API work earns its place

Start with the connectors already listed in each vendor's marketplace. Test one in a sandbox or test company with your real edge cases, such as an edited invoice, a refunded order, a customer with two contacts and a merged duplicate. Write down what the connector does with each case. If it handles your edits, deletes and IDs, and someone can see its errors, you may not need anything else.

A custom API integration earns its place when the connector cannot meet a written rule. Typical reasons include matching on your own IDs, combining data from three or more systems in one step, keeping an audit history, or handling a volume that makes per-task pricing expensive. Custom work also brings hosting, credential management and a maintainer, so compare the full running cost of each option over the same year before deciding.