Where an AI integration reads from: your system's API or a copy of its database
An AI integration can read from your warehouse system's API or from a copy of its database. Here is what each path needs from your IT team and how we choose between them.
Before an AI integration can warn you about a short pick or a late load, it has to see your data. The system that runs your floor holds that data, and it is busy doing the work your people depend on. The first design question is where the integration reads from, and how it does that without getting in the way.
We use two answers. The integration reads from your system's API, or it reads from a copy of the system's database. Neither takes over the system that runs the floor. They differ in what they need from your IT team and in what they can and cannot do.
Path one: reading through the system's API
An API (application programming interface, the set of doors a system offers so other software can ask it for data) is the front entrance. Many warehouse, order and dispatch systems offer one. The integration asks the API for what it needs, such as open orders or the stock at a location, and the system answers using its own rules.
The strength of this path is that the system stays in control. It decides what to share and applies its own permissions. If an integration also needs to put something into the system, such as an order keyed in from an email, that has to go through the system's own connections, and the API is usually where that happens.
The limits come from the same place. An API only offers what its makers chose to expose, so a field the integration needs may simply not be there. Every question is also work the live system does while it runs your floor, which matters on a busy day.
What it needs from your IT team
- Access to the API for the integration, with permission to see only what it needs.
- The system's documentation, or a person who knows which parts your sites use.
Path two: reading from a copy of the database
Most of these systems keep their data in tables in a database such as SQL Server, MongoDB or PostgreSQL. A copy of that database holds the same rows, kept up to date from the original, and the integration reads the copy instead.
The strength here is reach and distance. The integration can read the tables directly, including detail an API never exposed, and its questions land on the copy, not on the database your floor is using. That leaves spare capacity on the live system, so it stays resilient during peaks.
The limit is that a copy is for reading. Nothing written to it reaches the system that runs the floor, so an integration that has to enter something still needs the system's own connections. A copy also trails the original by however long changes take to arrive, and the integration has to be designed around that delay.
Where the copy comes from
When the data the integration needs sits at several sites, our warehouse sync add-on brings every site's data into one central copy. For SQL Server, it checks for changes on a short interval using change tracking (a feature built into SQL Server that notes which rows changed). Every change arrives at least once, so nothing is lost when a link drops, and the central copy is current to within a couple of minutes.
What it needs from your IT team
For the sync add-on, the list is short:
- A server, virtual machine or PC inside the site's network that can reach the database and reach the internet outward.
- A ranked list of the tables to copy, and any filters that put the most useful rows first.
- One technical contact for the first install. No port is opened to the internet.
How we choose between them
The choice is made in the design step, when we decide where the AI runs, what it reads and what it hands back. A few questions settle most cases.
- Does the API expose what the integration needs? If so, it is often the simpler path.
- Does the integration need to write back? Entering an order or booking an appointment goes through the system's own connections, whatever path the reading takes.
- How busy does the floor get? If frequent questions would load the live system during peaks, a copy keeps that load away.
- How many sites are involved? When the answer depends on data from several sites, often running different systems, one central copy is usually easier to read than several APIs.
- What does the link look like? Sites lose their connection and distant sites sit on slow links, so whichever path we pick has to cope and catch up.
Sometimes the answer is both. An integration that turns emailed orders into entries might read a central copy to look across sites, then use the system's own connections to enter the order.
Why the system that runs the floor stays in charge
Both paths share one rule: the integration never takes over the system that runs your floor, and that system keeps running it. The AI's output lands in the redfly Portal as alerts, suggestions and dashboards, and your people act on them.
Your people keep working in the systems they know while the integration is tested with a set of checks, then piloted by a small group on real work, then rolled out under our watch.
redfly works out with you which path fits each integration, then builds it against the systems you already run. You bring how your operation works today; choosing where the integration reads from is our part.