Getting your data out of RealGreen: exports, reports, and the API

You get data out of RealGreen three ways: built-in reports and list exports for one-time pulls, the API for programmatic access, and a nightly replicated copy of your database for anything serious. That is the complete answer, and you do not need anyone's permission to use any of them. In our experience most owners only ever use the first door, which is why their marketing runs on a spreadsheet exported in March and stale by May. Here we will walk through all three doors, show you how we build the customer master file marketing actually needs, and flag the export gotchas that quietly wreck campaigns.

What can you export without touching the API?

A fair amount. RealGreen's reporting screens will generate customer lists filtered by status, program, service, and geography, and most of them export to CSV. For a one-time project, that is genuinely enough: a mailing list for prepay letters, a count of active customers by ZIP, a cancel list for a win-back push. Ten minutes of clicking, one file, done.

The limits show up when you need the same file repeatedly. Manual exports depend on a person remembering to run them, remembering the exact filters, and remembering what they named the file last time. Every manual export is a snapshot that starts aging the moment it lands in the downloads folder. If a workflow depends on data that is fresh weekly or better, a human-run export is the wrong tool, because it will get skipped during spring rush, which is exactly when you need it most.

What does the API add?

The API turns exports into something a system can do on a schedule: pull customers, programs, invoices, and visit history, and write certain records back. That unlocks the recurring workflows: a marketing database that updates itself, dashboards that are never stale, automations that react to yesterday's activity instead of last quarter's.

The catch is that API keys carry monthly call limits, so you cannot treat the API like a live database and query it every time you want an answer. Serious integrations pull changes once a night into their own copy of the data and run everything against that replica. We wrote up the details in our RealGreen API guide, and the batch-versus-real-time design question in the sync architecture post. Short version: nightly replication is the workhorse, and live API calls are reserved for the few moments that truly need them.

Here is what that unlocks, and it surprises owners: once the replica exists, we can connect RealGreen to pretty much any platform out there that has an API, a Zapier connection, or a native connection. The hard half of every RealGreen integration is getting the data out cleanly and keeping it fresh. Do that once and the rest is wiring.

How do you build the customer master file?

Whichever door you use, the goal is the same: one table, one row per household, holding the fields marketing decisions get made on. If you can produce this file fresh every night, nearly every automation and report we write about becomes possible. The columns that earn their place:

• Identity: customer number, name, service address, email, mobile phone, and opt-in status for each channel.
• Status: active, canceled, or prospect, with cancel date and cancel reason where they exist.
• Programs: which programs and services are on the account this season, and which were on it last season.
• Money: current balance, aging bucket, prepay flag, and lifetime revenue.
• Activity: last visit date, last invoice date, and the most recent condition codes techs have logged.
• Origin: the marketing source code and the start date.

That is maybe two dozen columns. Resist the urge to sync everything: a 400-column extract nobody understands is how data projects die. Start with fields that trigger an action, and add columns only when a new automation needs them.

How often should the data refresh?

Match the cadence to the decision. A campaign list for a monthly email needs monthly data, and a manual export honestly covers it. Dashboards an owner checks weekly want weekly-or-better data. Automations that message customers about balances, visits, or quotes need nightly data, because a payment reminder built on two-week-old AR is how you dun someone who already paid.

Nightly is the standard for a reason: fresh enough for every marketing use case, cheap on API calls, and it never forgets to run. If a vendor proposes weekly refreshes for an automation product, ask them what happens to the customer who paid six days ago.

The export gotchas that bite everyone

Households and duplicate addresses. Long-tenured databases accumulate two records for one property: a spouse, a re-signup after a cancel, a mistyped address entered fresh. Export by customer and you will mail the same house twice, or text a we-miss-you offer to somebody currently on your schedule. Dedupe by normalized service address, not by name.

Inactive statuses that aren't. Inactive can mean canceled three years ago, snowbirding for the winter, or suspended for non-payment: three different situations, three different messages, one status flag. Pull the cancel date and reason alongside the status and segment on those instead.

Source codes on autopilot. If the office defaults every new customer to the same source code, your origin column is fiction, and every attribution report built on it inherits the fiction. Fix intake before you trust it: the lead-source tracking post covers how.

None of these are export problems, strictly speaking. They are database problems the export exposes. Budget a cleanup pass before the first campaign runs; our data cleanup guide is the checklist, and it is dull, necessary work that pays for itself the first time you do not text an active customer asking them to come back.

The takeaway: your data is not trapped in RealGreen, but it does not walk out on its own either. One-time pulls belong to the report screens. Anything recurring deserves a nightly sync into a clean master file, because every automation, dashboard, and campaign you build next is exactly as good as that file and no better.

Start this month

1. Run one manual export of active customers and score it honestly: how many duplicate addresses, missing emails, and defaulted source codes per hundred rows?
2. Write down the two dozen master-file columns above and mark which ones your current exports can actually produce.
3. Decide your refresh cadence per use case: monthly for the newsletter, nightly for anything that messages a customer about their own account.
4. If nightly is the answer, evaluate a synced integration rather than a calendar reminder to run exports by hand: here is how we handle it.
5. Schedule the cleanup pass for the off-season, before spring campaigns depend on the file.