Life Inside the Walled Garden: My Experience With the AppFolio APIs
Published August 11, 2026 by Doug Walters
There aren't many people out there building against the AppFolio APIs, which is part of why I wanted to write this up. AppFolio has made real progress in recent years, but it still feels like a “walled garden” in software terms — a lot of the functionality that lives in the AppFolio UI stays locked inside it. The Reports APIs (v1 and v2) have always been read-only, so at best they're useful for analytics and BI, but they were never going to power a real integration. The read/write Database API was originally gated behind the Max tier, which came at a significantly higher price point, so making the leap was expensive. Now that the Database API is available à la carte, the barriers to entry are finally coming down.
Start with the problem, not the API
Defining the problem you're trying to solve is still the critical first step in deciding which API to reach for.
The v1 Reports API has by far the fewest endpoints and filtering parameters, and it works over simple GET requests. It's fine for testing and prototyping, but unless you're maintaining a legacy analytics pipeline or automation that already depends on it, I'd skip it and go straight to v2.
The v2 Reports API expands the list of available endpoints and adds richer filtering through POST requests with JSON payloads. You still authenticate with a client ID and secret tied to a specific user, which makes credential rotation a little awkward — and can create real business continuity problems if an employee leaves and production credentials happen to be tied to their account. The nicer feature in v2 is the ability to retrieve saved reports by UUID. That means an end user can build a report in the AppFolio UI, hand the UUID to a developer, and the developer just calls that report rather than reconstructing the entire request from scratch.
The Database API: powerful, but hit-or-miss
My experience with the Database API has been a mixed bag, even after spending real time in the documentation.
A few things stood out:
- Credentials and docs live in a separate developer portal, not in the AppFolio web app itself, and access to that portal isn't automatically provisioned. Like a lot of things with this API, you have to formally request it.
- Developer roles and permissions can be managed by a developer admin, but permission to specific endpoints and custom fields doesn't work the same way — there's no self-service management for those. You have to request them from AppFolio every time you want to grant someone access to an endpoint or a custom field.
- The sandbox database isn't available by default either. You have to ask for it before you can use it for development. It almost feels like AppFolio is nudging people toward developing in production, which is definitely not a best practice.
- The documentation's naming doesn't always map to what the endpoint actually does. For example, it isn't obvious from the docs that “List All Bills” also covers “List One Bill (by Id)” — you just have to know to look there.
- Foreign keys for joins have been inconsistent. Some endpoints were missing them entirely until recently. They're starting to show up, but coverage is still spotty, and I've found cases where I needed both the Database API and the v2 Reports API together to make an application work end to end.
Then there's webhooks
Webhooks come bundled with the Database API and are configured in the developer portal. You subscribe to a “topic” — General Ledger Details, for example — and every matching transaction gets pushed to your listener URL. There's a proper verification process, and AppFolio gives good guidance on guarding against duplicate deliveries.
Where it gets complicated: both your sandbox and production databases fire webhooks at the same listener URL, and there's no way to scope webhooks to sandbox only. Once they're on, they're on for both. That means your listener has to figure out which database the webhook came from — and the database_id isn't something you can retrieve through the API at all. You have to go pull it from the URL of your AppFolio web app login page.
Where this leaves things
AppFolio has come a long way — from no API at all, to a read-only Reports API, to a genuine read/write Database API with a reasonable set of webhook topics for automation and integration work. Their growing Stack Marketplace suggests they're going to keep opening up database access to customers and partners. As the API offerings continue to mature, I expect we'll see a growing community of AppFolio developers building out a real ecosystem of prebuilt apps and custom tools that make the platform genuinely more useful to work with.