API Integrations: Connect a Disconnected Software Stack

When your software platforms do not share data automatically, the work of keeping them in sync falls on your people. Someone copies a new lead from the web form into the CRM. Someone else enters the booked appointment into the scheduling system. A third person updates the invoice status in the accounting platform. Every manual data transfer is a potential error, a time cost, and a delay that compounds as your team grows.

The backend integrations we build replace these manual transfers with automated data flows. A new lead submitted via web form triggers an automatic CRM record creation, a lead qualification check, and a scheduling invitation—all within seconds, without anyone touching a keyboard. But before you can build these flows, you need to understand the two fundamental patterns for moving data between systems: webhooks and polling APIs.

The cost of a disconnected stack compounds with scale. When you have ten technicians, manual data sync is annoying. When you have fifty, it is a full-time job. When you have a hundred, it is a department. The right time to fix the integration architecture is before it becomes a headcount problem—not after.

A polling API is one where your system periodically asks another system: "Has anything changed since the last time I checked?" You call the API on a schedule—every five minutes, every hour, every day—and process whatever new or changed records come back. Polling is simple to implement and works with almost any API. The downside is latency: if you poll every fifteen minutes and a critical event happens one minute after your last poll, you will not know about it for fourteen minutes.

A webhook is the inverse: instead of you asking, the other system tells you when something happens. You register a URL endpoint, and the source system sends an HTTP POST to that URL whenever a relevant event occurs—a new booking, a completed job, a failed payment. Webhooks give you near-real-time data, but they require you to have a publicly accessible endpoint that can receive and process incoming data reliably.

For most service business integrations, the right answer is a combination: use webhooks for time-sensitive events (new inbound lead, job status change, payment received) and polling for bulk data synchronization (nightly sync of job history, weekly reconciliation of customer records). n8n handles both patterns natively and is the automation engine we use most frequently for service business backend integrations—it supports webhook triggers without additional infrastructure and has built-in scheduling for polling workflows.

Before you build any integration, you need to answer one question for every data entity that flows between your systems: which system is the system of record? The system of record is the authoritative source of truth for a given piece of data. If a customer address exists in both your CRM and your scheduling tool, which one is correct when they differ?

Without a clear system of record, bidirectional integrations create update loops and data corruption. System A updates a record, which triggers a webhook to System B, which updates its record, which triggers a webhook back to System A—and now you have an infinite loop or, worse, a situation where the most recent write wins regardless of whether that write was accurate.

The pattern that works: designate one system as the master for each entity type. Customer records are owned by the CRM (HubSpot in most of our builds). Job records are owned by the scheduling platform. Invoices are owned by the accounting platform. Integrations write to the master system and read from it. When a downstream system needs a customer record, it queries the CRM rather than maintaining its own copy. This is architecturally cleaner and dramatically reduces the number of places you need to update when data changes.

Idempotency means that running the same operation multiple times produces the same result as running it once. In the context of integrations, it means that if your webhook handler receives the same event twice—because of a network retry, a timeout, or a bug in the source system—it does not create two customer records, two job entries, or two invoice line items.

Implementing idempotency requires an idempotency key: a unique identifier for each event that you store after processing it. Before processing any incoming event, you check whether you have already seen that idempotency key. If you have, you skip processing and return a 200 OK so the source system stops retrying. If you have not, you process the event and store the key.

Most webhook-based APIs include an event ID in the payload that you can use as the idempotency key. If yours does not, construct one from a hash of the payload fields that uniquely identify the event. This is not optional engineering—it is the difference between an integration that works and one that corrupts your data during the next retry storm. Our backend integrations implementations include idempotency handling by default. For a broader look at workflow design, see Workflow Automation for Service Businesses.

Integrations fail silently if you let them. An API returns a 429 rate-limit error at 2 AM, your integration stops processing, and nobody knows until a customer calls to ask why their appointment confirmation never arrived. By then, you have missed bookings, confused customers, and a technician who showed up to a job nobody confirmed.

Good error handling means: retry with exponential backoff on transient errors (429, 503), surface permanent errors (400 Bad Request, 404 Not Found) to a notification channel immediately, and log every event at a granularity that lets you reconstruct what happened when something goes wrong. At minimum, log: the event ID, the source system, the timestamp, the outcome (success or error), and the error message if applicable.

Observability goes one level higher. You want to know not just that errors occurred but whether your integration is keeping up with volume. Is there a growing queue of unprocessed events? Is the lag between a webhook being sent and being processed increasing? These are leading indicators that your integration is under stress before it breaks entirely. We build observability into every backend integration we deploy—alerts go to Slack so the team knows within minutes, not hours. See also Build vs. Buy: Integration Middleware for Service Cos for guidance on when to build custom observability versus buy it.

If you are staring at a disconnected stack and do not know where to start, start with the highest-value pain point. For most service businesses, that is one of two things: new leads not making it into the CRM fast enough, or job status updates not syncing back from the field to the office in time to take action.

For lead capture, the integration pattern is: form submission or inbound call triggers a webhook, creates a CRM contact, logs the lead source, assigns to a rep, and sends an immediate acknowledgment SMS or email. For job status, the pattern is: technician updates job status in the field app, webhook fires, CRM deal stage updates, customer notification sends, invoice draft creates. Both are two-to-three-system integrations that can be built and tested in a week.

Once these are working, you have a proof of concept that makes the case for expanding the integration architecture to cover the rest of your stack. That expansion is where workflow automation and lead qualification and routing patterns come in—but start with the one integration that will save someone the most manual work this month and build from there.