What is SaaS integration?

SaaS integration is the practice of connecting separate cloud applications so they share data automatically. Instead of a person copying a customer, an order or a stock level from one system into another, the integration moves it according to agreed rules, transforms it into the format each system expects, and handles the cases where the data does not line up. It covers the design decisions as much as the technical connection.

What is the difference between SaaS integration and an API?

An API is the doorway a system offers so other software can read and write its data. SaaS integration is everything you build around those doorways: deciding what should move and when, mapping fields between systems that name things differently, matching records, handling duplicates and failures, retrying safely, logging what happened, and monitoring the whole arrangement. The API is a component. The integration is the system.

Should we use real time or scheduled syncing?

Per flow, not per project. Real time suits anything a customer is waiting on, most obviously stock availability and order status. Scheduled batches suit high volume, low urgency data such as nightly financial summaries, price lists or reporting extracts, and they are cheaper to run and far easier to recover when something fails. A well designed stack normally uses both, and choosing real time everywhere is a common and expensive reflex.

How much does SaaS integration cost?

It depends on the number of flows, how clean the data is and how many exceptions your business generates. What matters more than the headline number is the shape of the pricing. Budget for ongoing cost as well as build, since maintenance and monitoring is typically twenty to forty percent of the total over time, and be cautious with per record or per order pricing because it turns a strong sales month into a larger bill. We quote a fixed build price plus a flat managed fee.

Can you integrate a system that has no API?

Usually, yes. Older and specialised systems often offer a scheduled file export, a database view, an emailed report or a secure file transfer, and any of those can be the basis of a reliable integration. It changes the pattern rather than ruling it out: file based flows are batch by nature, so we design around a sensible schedule instead of pretending they are real time. If nothing at all is available we will say so rather than build something fragile.

How long does a SaaS integration take?

A single well defined connection typically takes two to six weeks from scoping to live. A full stack across eight or ten systems is normally staged over a few months, with the highest value flow going first so the manual work drops early rather than at the end. The variable is rarely the build. It is how long it takes to agree the rules and how messy the historical data turns out to be.

What happens when one of our vendors changes their API?

It will happen, usually with limited notice. Under a managed arrangement the monitoring detects the failure the same day, we diagnose it, update the integration and replay anything that did not make it through. This is the main practical argument for a maintained integration over a script someone wrote once: the script does not stop working on the day it breaks, it stops working on the day somebody finally notices.

A plain English guide for people who have to make the call

SaaS Integration: How Cloud Systems Actually Get Connected

SaaS integration is the work of making separate cloud applications share data automatically, so a customer, an order or a price entered once appears correctly everywhere it is needed. It sounds like a plumbing problem. In practice it is a decision problem, and the decisions are what this page is about.

There are six patterns in common use, and they are not interchangeable. Picking the wrong one is why integrations that demo beautifully fall apart at month end or at peak trading. Below: how each pattern behaves, what it costs to keep running, the failure modes nobody mentions in the sales meeting, and how to choose.

Book an Integration Call (03) 9003 0111

Realistic ROI

6 patterns

In common use, not interchangeable

Choosing the wrong one is the most expensive mistake in this work

1 to 5% of records

Will always be genuine exceptions

Realistic for most stacks, the design question is where they go

45 connections

To wire 10 systems point to point

Which is why point to point stops scaling around six or seven systems

20 to 40%

Of total cost is ongoing, not build

Rough guide, budget for maintenance or it comes out of goodwill

Four Things That Decide Whether a SaaS Integration Works

Integrations rarely fail on the technical connection. They fail on four decisions that get made too late, or by nobody.

Which system owns each piece of data

Before a single field is mapped, one system has to be declared the owner of each data type: the store owns the product, the accounting system owns the invoice, the CRM owns the contact. Everything else reads. Skip this and two systems will spend a year politely overwriting each other, and you will only find out when a customer receives the wrong price.

How often data needs to move

Real time is not automatically better, it is just more expensive and more fragile. Stock levels on a busy store genuinely need to be near instant. A nightly general ledger summary does not. Matching the frequency to the actual business need, field by field, is the difference between an integration that hums along and one that spends its life hitting rate limits.

What happens to the records that do not fit

Every integration meets data it cannot resolve: a duplicate, a missing product, a refund against something deleted, a name with an apostrophe that breaks a lookup. The design has to say where those go. Silently dropping them is the single most common reason a business loses trust in an integration it paid for.

Who finds out when it stops

Integrations do not usually fail loudly. They fail quietly, when a vendor changes an authentication flow or renames a field, and the damage accumulates until reconciliation. Monitoring, alerting and a named owner are not optional extras added at the end. They are part of the design or they never happen.

The Six SaaS Integration Patterns

Most real stacks use three or four of these together. The skill is knowing which job each one is right for.

Direct link

Point to point

One system wired straight to another. Fast to build and perfectly sensible for two or three systems. The problem is growth: connecting ten systems this way can mean up to forty five separate links, each with its own credentials, rules and failure mode. Fine as a starting point, painful as a strategy.

Central layer

Hub and spoke

Every system connects once to a central integration layer that holds the rules, the mappings and the logging. Adding an eleventh system is one new connection rather than ten. This is the default shape for any business that expects to keep buying software, which is most of them.

Nightly file

Scheduled batch

Data moves on a timer, often as a file: a nightly sales summary into accounting, a weekly price list out to a store. Unfashionable and genuinely excellent for high volume, low urgency data. It is also the only option for older systems that offer a file drop and nothing else.

Instant trigger

Event driven

The source system announces that something happened (order placed, payment received, stock adjusted) and the integration reacts within seconds. Right for anything a customer is waiting on. It needs care: events arrive out of order, arrive twice, or do not arrive at all, so every action has to be safe to repeat.

Clean data

Middleware and transformation

The layer in the middle that reshapes data so each system receives what it expects: date formats, currency in AUD, GST handling, unit conversions, tax codes, matching a customer across systems that store the name differently. Unglamorous, and where most of the actual build effort goes.

Exception queue

Human in the loop

The deliberate design decision to route ambiguous records to a person instead of guessing. A short daily queue with the reason attached, rather than a silent skip. This is what keeps a small percentage of odd records from turning into a loss of confidence in the whole system.

What Gets Connected in Practice

Task	Traditional	Done Properly	Notes
Online order into accounting	Keyed in from a store export	Invoice created automatically	The most requested flow in Australian ecommerce, and the one where GST treatment and rounding need to be right on day one.
Stock levels across channels	Updated manually, often stale	Synced near real time	Overselling costs more than the integration. Buffers and safety stock are part of the design, not an afterthought.
New customer across systems	Typed into two or three tools	Created once, matched everywhere	Matching rules matter here: email, ABN and phone all fail in different ways, so most stacks need a combination.
Paid invoice updates the pipeline	Someone emails the salesperson	Deal stage moves automatically	Small flow, disproportionate effect on whether sales reporting is trusted.
Product and price changes	Maintained twice, drift over time	Pushed from the owning system	A clear source of truth stops the classic problem of the website advertising last quarter’s price.
Purchase order to supplier	Recreated in a second system	Raised once, tracked through	Works well as scheduled batch, since suppliers rarely need second by second updates.
Support ticket to customer record	Agent searches each system	Linked on arrival	Cuts handling time noticeably because the agent stops hunting across tabs.
A record that will not match	Skipped without telling anyone	Queued with the reason	The design choice that most affects whether people trust the numbers a year later.

Where SaaS Integrations Quietly Go Wrong

Nobody agreed the source of truth

Two systems both allowed to write the same field will overwrite each other in a loop, and the corruption spreads slowly enough that nobody links it to the integration. Fix it before build: one owner per data type, written down, everything else reads. This is the cheapest hour you will spend on the project.

Retries create duplicates

Networks drop, APIs time out, and a retry is normal. If the action is not idempotent, meaning safe to run twice, a retry creates a second invoice or a second order. Every write needs a stable reference so the second attempt updates rather than duplicates. This bites hardest at peak trading, when retries are most frequent.

Rate limits were never modelled

Vendor APIs cap how many calls you may make. An integration that is comfortable in July can be throttled flat in November when volume triples, and a throttled integration usually looks like a stopped one. Pace the calls, queue the backlog, and test at three times current volume before peak season, not during it.

Nothing is watching

An unmonitored integration is a liability with a countdown on it. You need failure alerting to a named person within the same day, a record level log of what moved and when, and a way to replay the failed items once the cause is fixed. A dashboard nobody opens does not count as monitoring.

Privacy obligations were treated as an IT detail

Moving customer data between systems is regulated under the Privacy Act 1988 and the Australian Privacy Principles. Know which country each system stores data in, use least privilege service accounts rather than a staff login, keep only the logs you need, and be able to honour a deletion request across every connected system, not just the one the customer contacted.

The whole thing lives in one person’s head

Undocumented integrations get replaced rather than repaired, because the risk of touching something nobody understands outweighs the cost of rebuilding. Insist that the system map, the ownership decisions and the field mappings are deliverables, and that they are updated whenever the integration changes.

How Yes AI Approaches a SaaS Integration

Pattern selection before build

We work out which of the six patterns fits each flow, and say plainly where a cheap scheduled batch will serve you better than an expensive real time connection. Getting this right up front is worth more than any amount of clever engineering afterwards.

Data ownership agreed in writing

One owner per data type, documented and signed off before any field is mapped. It is the least exciting deliverable in the project and the one that determines whether your data is still trustworthy in two years.

Built, hosted and monitored by us

Connections run on a managed cloud automation layer we operate, with alerting and record level logging from the first day. You do not run servers, patch anything, or keep scripts alive, and you can see what moved and when.

Exceptions designed in, not bolted on

Ambiguous records go to a short review queue with the reason attached rather than disappearing. Your team handles the handful that genuinely need judgement and ignores the thousands that do not.

From Tangle to Working Integration

Five steps. The first flow is usually live between weeks four and six.

Map the stack and the manual work

Every system, including the shared spreadsheets and the mailbox someone watches. We trace each data type from where it is created to every place it is retyped, and put hours against it.

Choose the pattern per flow

Real time where a customer is waiting, scheduled batch where volume is high and urgency is low, hub and spoke as the overall shape. We agree the source of truth for each data type at the same time.

Specify in plain English

Trigger, fields, direction, matching rules, duplicate handling, exception routing. Written so a finance manager can check it, not just a developer. You approve before build.

Build, test on real data, go live

Built against official APIs and tested on a copy of your actual data including the awkward historical records. Monitoring and idempotent writes from day one, then a watched go live on the highest value flow.

Monitor, tune, extend

Same day alerting on failures, tuning of matching and exception rules against real traffic, and new flows added to the same layer as your stack grows. Documentation updated each time.

FAQ

Get the Integration Design Right First

Book a call. We map your systems, recommend the right pattern for each flow, and give you a priced plan. The map and the recommendations are yours either way.