Connecting your business systems: APIs, integrations and data sync for SA small businesses and councils

Most South Australian small businesses, not-for-profits and councils run on a handful of separate systems: an accounting package, a CRM or client database, Microsoft 365, a booking or job system, online forms and perhaps an e-commerce store. Each works well on its own. The trouble starts in the gaps between them, where staff re-key the same customer, invoice or job into two or three places, copy spreadsheets around and chase errors at month end. Connecting those systems properly saves time and improves data quality, but a careless integration can quietly lose records, leak personal information or break the day a vendor changes its API. This guide explains the main options, how to plan an integration that keeps working, and what to ask a supplier. It is general guidance; check your own contracts, vendor terms and privacy obligations.

Signs your systems need connecting

• Double entry. Staff type the same customer, order or timesheet into more than one system.
• Spreadsheet glue. Exports and imports run by one person who knows the steps, and nobody else does.
• Conflicting records. The CRM, the accounting package and the mailing list disagree about a customer’s address or status.
• Slow follow-up. A web enquiry or form submission waits in an inbox before anyone acts on it.
• Reporting pain. Month-end or board reports need hours of manual reconciliation.

Start with a simple systems map

Before choosing a tool, draw the systems you use and the information that moves between them. For each flow, note the trigger (a new order, a paid invoice, a form submission), the data involved, how often it happens and who relies on it. Then decide the system of record for each kind of data: which system is the source of truth for customers, products, prices, invoices, staff and jobs. Most integration problems come from two systems both believing they own the same record. Classify the data too, so personal and sensitive information is handled with care; our information classification guide explains a simple scheme.

The main ways to connect systems

• Built-in connectors. Many cloud applications ship ready-made integrations with popular accounting, CRM, payment and email tools. Try these first: they are supported by the vendor and usually cheapest to run. Check what they actually sync, how often and in which direction.
• No-code and low-code workflow tools. Services such as Microsoft Power Automate, Zapier and Make connect apps with triggers and actions. They suit simple, low-to-moderate volume flows such as “new form submission creates a CRM contact and notifies the team”. Watch for flows built under one person’s account, missing error alerts and costs that grow with usage.
• Custom API integration. A small, purpose-built service that uses each system’s API or webhooks. It suits higher volumes, complex mapping or business rules, and flows that must be reliable and auditable. It takes more work up front but gives you full control over error handling, logging and security.
• An integration hub. When several systems need to share the same data, a central hub or message queue avoids a tangle of point-to-point links. Each system connects once, and new systems can be added without rewriting everything. Our Learn architecture for an API-led integration hub shows how the pieces fit.
• File and database methods. Older or on-premises systems without an API can often still exchange scheduled files or be read from their database through a secure agent. These are workable when planned carefully, with checks that each file arrived and was processed completely.

Design choices that make integrations reliable

1. Clear field mapping. Document how each field in one system maps to the other, including codes, tax settings, date formats and what happens to blank or unexpected values.
2. Matching rules. Decide how records are matched, for example by a customer number rather than a name, so duplicates are not created.
3. Safe retries. Networks fail and APIs have rate limits. The integration should retry automatically, and be designed so a retry never creates a second invoice or order (often called idempotency).
4. Error queues and alerts. Records that fail should go to a queue a named person reviews, with a clear reason, not disappear silently. Alerts should reach a shared mailbox or channel rather than one person.
5. Logging and audit trail. Keep a record of what was sent, when and with what result, without writing passwords or unnecessary personal details into logs.
6. Reconciliation. A simple daily or weekly check that counts and totals match on both sides catches problems before month end.

Keep integrations secure

• Least-privilege access. Use dedicated integration accounts or app registrations with only the permissions each flow needs, not an administrator’s login.
• Modern authentication. Prefer OAuth 2.0 with scoped, expiring tokens where the API supports it. Store API keys and secrets in a secrets vault, never in spreadsheets, emails or code.
• Owned by the organisation. Workflow tools and integration accounts should belong to the business, not a staff member’s personal account, so they survive staff changes. Our onboarding and offboarding checklist covers handing these over.
• Data minimisation and location. Only move the fields each system needs, and check where any middle-layer service stores and processes data, especially for personal or council information. See our data residency guide.
• Webhook checks. Verify that incoming webhooks are genuinely from the sender, usually with a signature, before acting on them.

Plan for change after go-live

Integrations are not set-and-forget. Vendors release new API versions and retire old ones, field names change, passwords and tokens expire, and business processes evolve. Keep a short register of each integration: what it connects, who owns it, where its credentials live, which API versions it uses and how to tell if it has stopped. Test integrations in a sandbox or test company before changes go live, and include them in your support arrangements. Our managed IT provider checklist explains what to agree for ongoing support.

Questions to ask an integration supplier

• Which system will be the source of truth for each type of data, and how will duplicates be prevented?
• What happens when a record fails or an API is unavailable, and who is told?
• How are credentials stored, and what permissions will the integration have?
• Where does data pass through or get stored along the way, and for how long?
• How will we know if the integration stops working, and how quickly can it be fixed?
• Who owns the code, workflows and documentation, and can another supplier take them over?

A practical starting plan

1. Map: list your systems, the flows between them and the system of record for each data type.
2. Prioritise: pick the one or two flows that cause the most re-keying, delay or errors.
3. Choose the method: built-in connector, workflow tool, custom API integration or hub, based on volume, complexity and risk.
4. Design and test: agree field mapping, matching rules, error handling and security, then test with realistic sample data in a test environment.
5. Go live with monitoring: turn on alerts and reconciliation checks from day one.
6. Review: check the integration register each quarter and before any vendor upgrade.

How EITSAA can help

EITSAA is an Adelaide-owned technology company working with SA small businesses, not-for-profits, councils and agencies. We map existing systems, recommend the simplest reliable way to connect them, and build integrations with APIs, webhooks, workflow tools or an integration hub, with error handling, monitoring and handover documentation included. Our Learn architecture for CRM and accounting integration shows a typical design. Get a quote for connecting your business systems or call 0402 401 584, Monday to Friday, 9am to 5:30pm. Learn more about our application development, intelligent automation and managed IT and cyber security services.