Most automation projects in this industry die in the same sentence: “our platform doesn’t have an open API.”
It is usually true. Several of the big property management platforms keep API access behind a partner programme, a minimum door count, an annual fee, or all three. If you manage two hundred units, you are very likely not getting a key.
And it almost never matters. Here is the part nobody tells you.
An API is a delivery mechanism, not a superpower
Strip away the word and an API is just this: a way for one system to hand data to another without a person carrying it.
That is the whole trick. Anything that hands data to another system on a schedule does the same job. And every platform on this list already has one of those built in, switched on, and free:
The scheduled report.
You almost certainly already use it. Somebody at your company gets a rent roll on the first of the month, or your bookkeeper gets a delinquency report every Monday. That is a data feed. It is just addressed to a human instead of a machine.
Point one at a machine and you have the input for most of what you actually want to build.
What this can and cannot do
Be clear-eyed about it, because the limits are real.
It works well for
- Anything where the data changes daily rather than by the second — delinquency, vacancy, lease expirations, deposit deadlines, work order ages, owner statements.
- Anything that ends in a message. Reminders, notices, escalations, reports to owners, alerts to your team.
- Anything you currently do by opening a report and working down it by hand. That is the giveaway: if a person reads a list and acts on each row, a machine can read the same list.
It does not work for
- Writing back into the platform. A report is a one-way street. If the automation needs to mark something paid or close a work order inside your software, you need either a real API or a person.
- Anything that has to happen in seconds. A report on a two-hour cycle means your data is up to two hours old. Fine for rent chasing. Not fine for an emergency maintenance call, which needs a different route entirely.
- Anything not in a report. If a field is not on any report your software can produce, this approach cannot see it.
That still leaves a lot. In our experience the majority of what a company this size wants automated is read-and-message, not read-and-write.
Setting it up, step by step
1. Find the scheduler
Every one of AppFolio, Buildium, Rent Manager, Yardi Breeze, DoorLoop, Propertyware and Rentvine can build a custom or saved report and email it on a recurring schedule. The menu names differ — look for reporting, then for a saved or custom report, then for a delivery, subscription or schedule option on that report.
If you cannot find it, ask your account manager for “scheduled report delivery” by name. It is a standard feature, not an upgrade.
2. Choose the columns deliberately
This is where most people go wrong. They export everything, reasoning that more data is safer. It is the opposite: a wide report is slower, more fragile, and more likely to change shape when someone edits it.
Include only what the automation needs, and always include a stable unique identifier — a unit ID, a lease ID, a tenant ID. Not a name. Names change, duplicate, and get typed three different ways. An ID is the thing that lets tomorrow’s report be compared against today’s.
A rent-chasing report needs roughly seven columns:
- lease or tenant ID
- unit identifier
- tenant name
- mobile number and email
- amount outstanding
- days past due
- date of the last payment received
That is enough to send a correctly worded, correctly escalated message to the right person. Everything else is noise.
3. Send it somewhere a machine is listening
Create a dedicated address — something like reports@ your domain — and send the schedule there. Do not use a person’s inbox, and do not use a shared inbox people work out of. You want an address where the only thing that ever arrives is these reports.
This one decision prevents most of the problems that come later. A mailbox with a single kind of message in it is trivially reliable. A mailbox with a hundred kinds is a permanent source of edge cases.
4. Pick the cadence honestly
Ask what the automation actually needs, not what feels thorough:
- Rent chasing: once a day, early. Nothing about a late payment gets better by knowing four hours sooner.
- Deadline tracking: once a day is plenty. These are dates, and they move slowly.
- Vacancy and turns: a few times a day if you are actively turning units, once a day otherwise.
- Owner reporting: monthly, on a fixed day.
More frequent is not better. Every run is a chance for something to go wrong, and a report that arrives hourly gets ignored the same way a smoke alarm with a low battery does.
5. Diff it, do not just read it
Here is the step that separates something that works from something that annoys everyone.
Do not act on every row of every report. Compare today’s report against yesterday’s and act on what changed.
A tenant who was five days late yesterday and is five days late today does not need a second identical message. A tenant who moved from three days late to six days late has crossed a threshold and needs the next message in the sequence. A tenant who paid needs the sequence to stop immediately — and stopping is the part people forget, and the part that generates the angry phone call.
This is why the stable ID matters. Without it you cannot reliably tell that row 41 today is row 38 yesterday.
Four rules that keep it working
Automation built on scheduled reports fails in exactly four ways. All four are preventable.
Freeze the report
The moment someone edits the saved report to add a column for a one-off question, your automation is reading a different shape than it expects. Name it something that says so — AUTOMATED — do not edit — and make a copy for anyone who wants to explore.
Add a canary
Have the automation notice when a report does not arrive. Silence is the most dangerous failure, because nothing looks wrong. If the expected report has not landed within an hour of its scheduled time, someone should get a message. A rent-chasing sequence that quietly stopped in March is much worse than one that never existed.
Handle the empty report
One morning nobody is late. The report arrives with headers and no rows. That case has to be explicitly handled, or you will find your automation either crashing or — far worse — treating an empty file as a signal to do something dramatic.
Keep a human threshold
Decide what the automation is never allowed to do alone. Most companies draw it at anything with legal consequence: a notice, a filing, a lease termination. The system prepares it and puts it in front of a person on the right day. That is the useful part — the remembering, not the sending.
A worked example
Rent chasing, end to end, built entirely on a report:
- A delinquency report runs at 6am daily and emails to
reports@. - The automation opens it, reads the rows, and compares them against yesterday’s by lease ID.
- Anyone newly past due gets the first message — short, in your voice, with a payment link.
- Anyone who has crossed the next threshold gets the next message in the sequence, once.
- Anyone who has left the report since yesterday has paid. The sequence stops for them, and nothing further is ever sent.
- Anyone at your notice threshold is not messaged automatically. Their notice is drafted with the right figures and appears on a list for a person to review that morning.
- If the report has not arrived by 7am, the operations lead gets a text.
No API. No integration. No permission from anybody. Your platform stays exactly as it is, and your team keeps working where they already work.
The honest catch
None of this is difficult in concept, and all of it is fiddly in practice. The report changes shape. A vendor updates a template. A state changes a notice period and the thresholds move. Something upstream breaks roughly every few months, and somebody has to notice and fix it.
That is the real cost of automation, and it is the part that is almost never budgeted. The build is days. The keeping-it-alive is forever.
If you have someone technical who can own that, this is a genuinely good weekend project and you should do it. If you do not, that maintenance is most of what you are actually buying from anyone you hire — including us.
Either way, do not let “we don’t have an API” be the reason nothing gets automated. It was never the blocker.