How to Connect AI to Your Existing Business Systems
The hard part of AI automation is rarely the AI. It is getting data out of the systems you already run, and putting results back in without breaking anything.
Most AI automation projects are integration projects with a model somewhere in the middle. The interesting part is small; the work is in connecting to what you already run.
This is also where projects stall. Halfway through a build, someone discovers the system holding the critical data does not expose it in any usable way.
Worth checking first.
The integration options, best to worst
A proper API
The system offers documented endpoints for reading and writing data. This is what you want.
What to verify before relying on it:
- Does it cover what you need? Many APIs are read-heavy - plenty of ways to get data out, few to put it back.
- What are the rate limits? They decide how fast your automation can run.
- Is authentication sane? OAuth or API keys are fine. Systems requiring a session cookie obtained by scripted login are fragile.
- Is it stable and versioned? An API that changes without notice becomes a maintenance burden.
Webhooks
The system notifies you when something happens, rather than you polling for changes.
Better than polling: near-instant, and no wasted requests. Where available, use them.
Practical requirements: verify the signature so you know the request is genuine, respond quickly and process asynchronously, and expect duplicates - the same event can arrive twice, so make handling idempotent.
An automation platform
Tools like Zapier, Make or n8n sit between systems and handle the connection.
Genuinely useful, and often the right answer for straightforward workflows. Pre-built connectors save real time, and non-developers can maintain simple flows.
Where they stop fitting: complex conditional logic, high volume (per-operation pricing adds up), sophisticated error handling, or anything needing careful state management. There is a point where a platform workflow becomes harder to reason about than code doing the same thing.
We use them where they earn their place and write code where they do not. That decision should be based on the workflow, not on preference.
Direct database access
Reading directly from the database behind an application.
Sometimes the only option for older systems. Read-only access to a replica is acceptable if you must.
Writing directly is a different matter, and we would generally advise against it. Applications enforce business rules above the database - validation, derived fields, audit trails, cache invalidation. Writing underneath the application bypasses all of it, and the corruption may not surface for weeks.
File-based exchange
Scheduled exports to a folder, imports picked up on a schedule. CSV, XML, whatever the system produces.
Inelegant and entirely workable. Many established business systems support scheduled exports even when they have no API.
The constraints: it is batch, not real-time; you need to handle partial and malformed files; and you need to track what has already been processed.
Screen scraping and browser automation
Driving the user interface programmatically because nothing else is available.
Genuinely a last resort. It breaks whenever the interface changes, it is slow, it may violate terms of service, and it is difficult to make reliable.
Occasionally it is the only path. If you go here, isolate it behind a clean interface so the rest of your system does not depend on its fragility, and expect ongoing maintenance.
When the system is genuinely closed
Some software has no API, no exports and no database access. Options:
Change the entry point. Instead of integrating with the closed system, put your automation earlier in the process - capture data at the point it enters, before it disappears into the black box.
Automate around it. Handle everything upstream and downstream, leave the one manual step in the middle. Often still worth it.
Ask the vendor. More systems have undocumented integration options than you would expect, particularly on higher tiers.
Reconsider the system. If a core system blocks every improvement you want to make, that is information about the system.
Things that catch people out
Authentication expiry. Tokens expire. Handle refresh properly, and alert when it fails rather than silently stopping.
Rate limits under load. Fine in testing at ten records, throttled in production at ten thousand. Build in backoff.
The unhappy path. Third-party services have outages, time out, and return unexpected responses. Every integration needs to handle failure explicitly - retry with backoff, then stop and alert. Silently dropping work is the worst outcome.
Field mapping drift. Someone renames a custom field in the CRM and the automation starts writing to nothing. Validate that expected fields exist rather than assuming.
Test environments that differ from production. Sandbox APIs sometimes behave differently. Verify against production behaviour before trusting it.
Data volume in the first sync. Backfilling two years of history is a different problem from handling new records. Plan for it separately.
Where the model actually sits
Worth being clear about the architecture, because it is simpler than people expect.
Your systems talk to your automation layer. The automation layer calls a model for the specific step requiring interpretation. The model does not connect to your systems, does not have credentials, and does not decide what actions to take.
That separation matters. It keeps the model as a component doing one job - turning unstructured input into structured output - rather than as something with access to your business. Validation and actions stay under your control, in deterministic code.
Before committing to a build
- List every system involved. For each: API, webhooks, exports, database access, or nothing?
- Read the API documentation properly. Confirm the specific operations you need exist.
- Check rate limits against your expected volume.
- Build a spike. Before scoping the full project, prove you can read and write the data. This is a day of work that regularly saves a month.
- Decide where state lives - what has been processed, what is in progress, what failed.
- Plan the failure path for every external call.
Step four is the one worth insisting on. Most automation projects that go badly do so because an integration assumption turned out to be wrong, and it was discovered late.
We start integration work with a spike for exactly this reason. Tell us which systems are involved and we will tell you what is feasible before anyone commits to a scope. More on AI automation and app development.