Realhub and Campaigntrack Replace Dropbox, Egnyte, and ShareFile With Files.com

Domain Group is an Australian property technology business. Its Realhub and Campaigntrack brands build real-estate marketing campaign products that take property listing data and marketing assets from agency CRM systems and produce campaign collateral.

Both platforms embed into the systems agencies already run rather than replacing them. A campaign is built from a property listing, and that listing's data and marketing assets live in whichever CRM the agency already uses. So both products depend on one thing happening reliably every day: around thirty external CRM and listing platforms, none of which Realhub controls, pushing property data and marketing assets in.

Realhub and Campaigntrack replaced Dropbox, Egnyte, and ShareFile with one Files.com intake layer, giving each partner an isolated transfer credential while webhooks and the API handled roughly 50,000 application calls a day.

The Front Door of Both Products Ran on Dropbox, Egnyte, and ShareFile

That intake ran across three file-sharing products: Dropbox, Egnyte, and ShareFile. What was pushing files in was not a person. It was thirty unattended systems, each delivering on its own schedule with its own tooling, into two products that consume those files programmatically.

Connecting a new CRM vendor meant supporting partner deliveries across three separate services. On the collection side, Realhub's applications needed to detect and pick up every partner's delivery. At that scale, the model required Realhub to maintain multiple machine-to-machine intake paths instead of one standard transfer surface.

The Only Common Denominator Across Thirty Vendors Was a Standard Protocol

What made the problem hard was that Realhub controlled neither end of it. The partners were independent software vendors, each pushing on its own schedule with its own tooling, and the only interface all thirty could realistically be asked to use was a standard transfer protocol like SFTP, with a credential of their own. The downstream side had to be the opposite of manual: two campaign products collecting every delivery programmatically. And the estate had to serve two brands, Realhub and Campaigntrack, each with its own product organisation, without doubling the administration.

The intake layer had to speak a protocol every partner already spoke, isolate each partner behind its own login, hand every delivery to an application the moment it arrived, and keep two product lines separate under one roof. Realhub selected Files.com to be that layer.

SFTP In, Webhooks and API Out

Files.com became the single intake edge between the partner network and both campaign products.

On the partner side, each of the roughly thirty CRM integration partners received its own SFTP or FTP login on Files.com. A new partner received its own credential and drop point, then connected with the transfer tooling its platform already had and started pushing listing data and marketing assets.

On the application side, pickup became event-driven. Files.com webhooks fired the moment a partner's delivery landed, and Realhub's applications collected the files through the Files.com API. That machine traffic ran at roughly 50,000 API calls a day across both sites, with no person in the loop.

The two brands were configured as a Files.com parent and child site: one site for Realhub and a child site for Campaigntrack. Each product line kept its own site and boundary, while administration and usage rolled up to one place. Two product organisations shared one intake pattern instead of maintaining two.

Partner Onboarding Became a Repeatable Transfer Pattern

With the Files.com sites in production, Realhub and Campaigntrack replaced an intake split across three file-sharing tools with a single pattern built for machine traffic.

• Onboarding a new CRM partner at the transfer layer is a repeatable step: provision an SFTP credential and hand it over. The partner connects with the tooling it already runs.
• Delivery pickup runs unattended. Webhooks announce each file as it lands and the applications collect it through the API, so partner data flows into the campaign products with nobody moving files by hand.
• Three file-sharing products became one intake layer. Dropbox, Egnyte, and ShareFile are out of the path, and both product lines run the same pattern under one administration.
• The platform is a transit surface, not an archive. Combined storage across both sites sits at about 65 GB against tens of thousands of daily API operations because files pass through rather than pile up.

Together, repeatable provisioning, unattended pickup, and one shared intake pattern let a small integration team run the entire thirty-partner network.

One Standard Surface for a Network Realhub Doesn't Control

File intake at Realhub stopped being three separate paths through file-sharing products and became a standing capability of the business: an isolated credential per partner on the way in, events and an API on the way out. A partner network Realhub doesn't control now meets its products through one surface Realhub does.