Property Management / Updated August 2026
Guide / By Rob Lowry, Founder of LaunchEngine
The AppFolio API: the integration paths that actually work
Ask whether AppFolio has an API and you'll get three different answers depending on who you ask, none of them complete. The truth: there are several sanctioned paths, each with different access rules, and no public developer portal tying it together. We build monday.com operating systems for property management companies on AppFolio, connected through each client's own sanctioned API access, so here's the map we wish had existed, including the exact questions to ask your AppFolio rep.
8 min read
AppFolio takes a different approach to integrations than Buildium or Rentvine: instead of a public developer portal, access is arranged account by account, and much of what the platform can do programmatically isn't written down anywhere you can Google. That's not a reason to write it off. Real integrations run on AppFolio every day, all built on the sanctioned paths below. It just means the map matters more.
This guide covers the sanctioned paths, what each one is actually like to build on, the pattern most tools quietly use, and the one approach you should rule out entirely.
01 / The map
Four ways in, at a glance
| Path | Access | Direction | Best for |
|---|---|---|---|
| Reports API | Client ID + secret from Manage API Settings | Read-only | Dashboards, ops sync, financial reporting |
| Database API | Tier-gated (reported: Plus read, Max read/write), client-provisioned | Read, or read/write on the top tier | Deeper two-way integrations |
| Stack partnership | Partner application, security review, program fees | Per integration agreement | Vendors selling to many AppFolio customers |
| Scheduled reports + email | Any plan, no API at all | One-way out | Simple feeds, alerts, low-volume syncs |
"Reported" items reflect public documentation from integration platforms that build on AppFolio, current as of August 2026. Confirm specifics for your account with AppFolio.
02 / The workhorse
The Reports API: every report, as JSON
This is the path most working AppFolio integrations are built on, and the mental model is refreshingly simple: anything you can run as a report in AppFolio, you can fetch as JSON. Each of the 60+ reports (rent roll, income statement, balance sheet, aged receivables, work order status, and so on) has its own endpoint:
POST https://{yourdb}.appfolio.com/api/v2/reports/rent_roll.json
Authentication is HTTP Basic with a client ID and secret created in AppFolio under Manage API Settings. Requests are POSTs with optional JSON filter parameters, mirroring the filters you'd set in the report UI. Results paginate at 5,000 rows with a next_page_url link that stays valid for 30 minutes, and the commonly cited rate limit is 7 requests per 15 seconds, with next-page fetches exempt, so large pulls stream quickly once started.
The constraint to design around: it's read-only, and it's report-shaped rather than object-shaped. You're not fetching "a tenant"; you're fetching rows from a report that contains tenants. Good integrations treat each report like a table, sync it on a schedule, and diff against the previous pull to detect changes.
03 / The gated tier
The Database API, and the questions to ask your rep
Above the Reports API sits a higher-level Database API whose capabilities aren't publicly documented. What's been reported by integration platforms that build on it: access follows plan tier, with read-only on Plus and read/write on Max, and credentials are provisioned by the customer for a named vendor rather than self-served.
Because the details live behind sales conversations, the most useful thing we can give you is the checklist we'd use in that conversation:
- 01Which API access does my plan include. Ask specifically about the Database API and the Reports API on your current tier, and what an upgrade would add. Get the answer in writing, since capabilities are not publicly documented.
- 02What objects can we read, and what can we write. If write-back matters (work orders, tenants, leases, GL), ask for the concrete list of writable objects on your tier, not a general yes.
- 03How are vendor credentials provisioned. Database API credentials are provisioned per client for a named vendor. Ask about the process, turnaround, and whether your integration partner needs to be Stack-registered for your use case.
- 04What are the rate limits and data volume terms. The Reports API's commonly cited limit is 7 requests per 15 seconds. Ask what applies to your account, especially if you plan frequent syncs across a large portfolio.
- 05Is there a test environment. There's no public sandbox. Ask how integrations should be tested against your database without touching production workflows.
04 / The use cases
What one-way data is genuinely enough for
A lot of teams assume they need two-way sync and then never use it. These patterns, all built on the read paths, cover most of what PM operators actually want:
- 01Rent roll and financials into your dashboards. The Reports API's 60+ reports include rent roll, income statement, balance sheet, aging, and workflow reports. Polled on a schedule, they feed BI dashboards and owner reporting without anyone exporting a CSV again.
- 02An ops mirror in your coordination tool. Pull properties, units, tenancy, and balances from reports into the system where your team actually runs the work. This is what we build for AppFolio-based clients: portfolio data lands in monday.com boards where renewals, maintenance, and onboarding live, fed through the client's own sanctioned API access.
- 03Delinquency and exception alerts. Aging and balance reports polled daily become Slack or task alerts when a number crosses a threshold. One-way data is plenty for watchdog workflows.
- 04Email notifications as event triggers. AppFolio's email notifications, parsed by your automation layer, approximate webhooks: a work order email becomes a task in your ops board within minutes, no API access required.
- 05Scheduled reports as a zero-API integration. Recurring report emails parsed into another system are the humblest integration path and often the right first step. If the report has the columns you need on the schedule you need, you may not need API access at all.
05 / The dead end
Browser automation is not an integration strategy
When a rep can't articulate API capabilities and the docs aren't public, someone on your team will eventually suggest pointing a browser bot at AppFolio to click the buttons a human would. Don't. It's contrary to AppFolio's terms of use, and AppFolio actively detects and blocks automated browsers. Whatever you build that way will break without notice, and the failure mode isn't just a broken workflow, it's a conversation about your account.
Treat the boundary as a design constraint. Between the Reports API, scheduled reports, email-notification triggers, and the gated write paths, there is almost always a sanctioned route to the outcome you want, and the sanctioned route is the one that still works next quarter.
06 / Build vs. buy
What a production AppFolio integration takes
Building on AppFolio means engineering around its shape: report-diffing instead of webhooks for change detection, a scheduler that respects the rate limit across a whole portfolio, parsers for the email-notification triggers, and an access conversation with AppFolio for anything two-way. It's all tractable, and it's what we build for clients through their own sanctioned access, but the integration is as much operational discipline as code.
The buy option
We build PM operating systems for companies on AppFolio
LaunchEngine builds monday.com operating systems for PM companies on AppFolio: renewals, move-ins, maintenance, and owner workflows coordinated against your portfolio data, connected through your account's own sanctioned API access. Same operating system we run on Buildium and Rentvine, adapted to AppFolio's integration model, live in about 10 days at $1.30/door/month.
Disclosure: this guide is written by LaunchEngine, and the buy option is ours. The AppFolio facts above are compiled from public sources and our own experience, so the build-vs-buy math is yours to run either way.
Building something custom?
Get an AppFolio API Review before you commit the architecture
If you're scoping custom work against AppFolio (a reporting pipeline, an internal tool, your own product), bring your plan to a 30-minute working session. We'll pressure-test it: which path fits your access level, report-diffing design, rate-limit budgeting across your portfolio, and what to negotiate with your AppFolio rep before you write code.
The short version
AppFolio has real APIs; it just doesn't have a public map of them. The Reports API turns all 60+ reports into JSON and carries most working integrations. The Database API adds tier-gated depth, with write access reported on the top plan. Stack partnership is the vendor route. Scheduled reports plus email notifications cover the simple cases with no API at all. And browser automation is the one path that leads nowhere. Walk into the rep conversation with the question list from section 03, and get every capability claim in writing.
About this guide
This guide is for informational purposes only and does not constitute financial, legal, or business advice. AppFolio does not publish plan or API pricing; details here are compiled as of August 2026 from AppFolio's public materials, publicly available third-party integration documentation, and LaunchEngine's experience building on these paths through client-provisioned access, and may change or vary by account. Confirm all capabilities, tiers, and terms with your AppFolio representative. AppFolio is a trademark of its owner. This guide was written by LaunchEngine and is not authored, reviewed, or endorsed by AppFolio. Spot an error? Email rob@launchengine.com and we'll correct it.
FAQ
Common questions about AppFolio's APIs and integration options.
Want your AppFolio data working for you?
Book 30 minutes and we'll show you a live PM operating system running on portfolio data, or review the custom AppFolio build you're planning.