A Specialty Pet Retailer Uses Files.com Logs to Rebuild Its ERP File Exchange and Cut API Volume

A specialty pet retailer sells pet food and supplies under two banners. Its group IT team supports both banners and the systems the company’s employees use.

Retail at that scale is a file business. Inventory and order data moves constantly between the ERP, the e-commerce platforms, and the workforce systems, and those integrations were built up over years. The retailer wanted every one of them observable per account and per operation, and built on a pattern its own team can read end to end. Files.com logs showed that one of the most important, the file exchange feeding the ERP, was handling the same file dozens of times over. The group’s head of system administration and security used that evidence to retire the Core FTP scripts, rebuild the integration on the company’s proven pattern, and cut daily API volume sharply.

A Polling Integration on the Core ERP Data Flow

The files themselves moved through the retailer’s Files.com site. The process moving them lived outside it: the Core FTP client, driven by PowerShell scripts and fired by scheduled tasks. It polled folders on a schedule, picked up files, and pushed them along, and it sat on the company’s core ERP data flow.

The one place the process could not hide was the platform it ran against. The retailer’s Files.com account was recording far more API calls than the company’s real file traffic could explain. The administrator decided the exchange had to be observable per account and per operation, and built on a pattern the company had already proven.

The Same File, Processed Dozens of Times

Files.com logs every operation on a site: which account acted, what it did, on which file, and when. The administrator filtered that record down to the integration’s service accounts and read the root cause straight out of it. Each file generated a cycle of API calls, and the same file was going through that cycle dozens of times, multiplied across every file the exchange handled, every day.

The administrator had the failure named, measured, and attributed to specific accounts and folders, straight from the record.

Rebuilt on a Pattern That Already Ran Clean

Rather than repair the scripts, the administrator retired them. The retailer had already built a clean exchange between Files.com and the company’s workforce platform: a dedicated service account for the integration, access confined to its own folder, and the application driving file movement directly through the Files.com REST API. That exchange had never shown the redundant behavior, so it became the model.

The administrator rebuilt the ERP exchange the same way. Core FTP, the PowerShell layer, and the scheduled tasks came out. The application now talks to Files.com itself under a service account that can reach only the folders that belong to it. Then the team used the same logs that had surfaced the problem to prove the fix held.

Daily API Calls Fell Sharply

With the rebuilt exchange in production, the retailer replaced a script process with an integration it can read end to end.

• Daily API volume fell to a fraction of what it had been, and subsequent review confirmed the application changes were permanent.
• The ERP exchange runs in-house. The retailer can read it, change it, and verify it against the log.
• “Is this integration working correctly?” is now a lookup. The logs show which account performed which operation on which folder, so any claim about an integration’s behavior can be checked against the record.
• The pattern compounds. A scoped service account, its own folder, and direct API calls is now how the retailer’s ERP, e-commerce, and workforce platforms exchange files.

The Exchange Layer the Retailer Now Builds On

Today, Files.com sits between the systems that run the business. The retailer’s ERP, e-commerce, and workforce platforms trade files through the site under scoped service accounts, and the Files.com on-premise Agent carries files down to the on-premises servers where the company’s e-commerce processing runs. The retailer keeps building on Files.com rather than assembling the same capabilities itself on raw cloud infrastructure because of the complexity of recreating its features on AWS.

A question about a misbehaving integration is now a query the retailer’s own team runs against the logs. The company never fixed the scripts. It removed the polling layer and let the application talk to Files.com directly, and the exchange pattern built in their place is the one it reaches for every time two of its systems need to trade files.