AppFolio API usage: 30 days, and the cut plan

One row per report, per customer. Measured = Western Slope's 30-day average per day. "Day" = 7 AM to 9 PM property-local; "night" = 9 PM to 7 AM. Today nothing slows down at night: 41% of calls land between 9 PM and 7 AM.

Measured = count of the sync Lambda's "GET …/reports/<report>.json" log lines for westernslopepm. One-minute jobs read below 1,440 because throttled ticks are skipped. The web app's hourly crons are not in these logs; by design they add at most a few hundred a day (estimate).

• We still hit AppFolio's rate limit every day. Real "429" answers in 30 days: JP&Co 4,122, Situs 5,071, Western Slope 2,244; steady state 30 to 70 a day per customer. Fede's rule from Sep 12 is "we should never be hitting rate limits." The plan should take this to zero, and the same query checks it.
• A test-property loop hit a live customer's database for three days. Oct 23 to 25, something pulled rent roll and rental applications for the Willows test property (JP&Co's database, shared with Camellia) about 7,700 times a day, with about 1,000 rate-limit errors a day. It stopped on its own Oct 26. Cause not traced; follow-up owner: this session.
• The nightly metrics job, corrected. It does go through the request budget (unlabeled caller), and the real volume is about one income-statement request per building per night for the 30-day income and spend figure, whose saved answer is keyed by a date range that moves daily so it is never reused. The labor-rate pull is 2% of it. Three quarters of the log lines I first counted were budget waits, not requests.
• The renewal worker pulls the charge detail about 100 times a day at JP&Co (3,025 in 30 days). That looks like a stuck retry on one or two renewals. Inference, not confirmed.
• History. Cadences were set in April from how fast Clara should react, never from a budget. Sep 12 set three speed classes (1 minute, 5 minutes, hourly) after Western Slope's first import made 25,000 calls in 3 hours. Nobody has revisited them since.

This is a fix to live behavior: no switch, live everywhere on merge, proven as below. The only owner step is picking A, B or C.

1. Day after deploy: re-run the same per-report count on all three databases; every row at or under its "after" number, and real 429 answers at zero.
2. Lead speed unchanged: time from a guest card appearing in AppFolio to Clara's first reply at Western Slope, the week before versus the week after, read from the conversation records.
3. A real move-in at Camellia or Western Slope shows in PropFlow within 15 minutes of the rent roll; the resident's phone and email arrive on the next daily pull.

• Yes, it is PropFlow, not Orca. We read AppFolio's reports on a timer to learn about new leads, work orders and move-ins.
• We agree with Andrew: the tenant directory does not need a 5-minute pull. We are cutting total calls by about two thirds and the directory to once a day.
• Guest cards and work orders stay near real time in the day; that is what lets Clara answer a lead or a repair request within a minute.
• Take Andrew up on the detailed per-endpoint data; we will reconcile it against ours.
• Lease dates and the three balance side reports are now hourly; tenant directory daily; expected ~40% below the original volume.
• Ask Jason whether these calls cost him anything today. Andrew's "save you some money" suggests they might; we cannot see that side.

Clara never asks AppFolio live when a resident texts or calls. Balance, lease end, work-order status and who-is-this all come from our copy. The balance answer already treats anything under 24 hours old as current. Lease end comes from the rent roll, not the lease-dates report. Unit vacancy feeds the advertised rent Clara quotes to prospects at every property and is Camellia's availability source since Oct 2, so it stays, slower where no property uses the source. The tenant directory is what gives Clara a resident's phone and email, co-signers, and residents who signed but have not moved in yet.

How residents reach us, last 30 days (production conversation records; residents only):

So the three balance reports plus the lease-dates report, about 1,500 calls a day per customer, serve roughly ten questions a month per customer, and 3.7% of resident contact happens overnight. Prospects are the daytime traffic, and that is the guest-cards pull.

Revised plan: what is safe tonight and what needs design

Tonight's PR (applications, balances) takes Western Slope from ~6,550 to ~4,600 a day (−30%) with no visible change. The rest of plan A follows once the day/night gate exists, landing near ~2,200.

Baseline. Every figure below is against the Oct 1–22 average at Western Slope: 6,808 calls a day (CloudWatch, one line per request). Counts after Oct 23 are not a baseline; see the bug.

What Fede decided

Net at Western Slope once everything above lands: about 40% fewer calls a day. Getting past that means touching guest cards or work orders, which Fede ruled out.

A live bug found on the way: the 5-minute tick has been starving itself since Oct 23

A budget change merged Oct 23 reserves part of each account's request budget per cadence class. In every 5-minute tick the balances job spends the budget first; the occupancies job then asks for the tenant directory, is refused by our own budget, and skips the whole tick, taking the unit-vacancy refresh with it. Measured Oct 26: occupancies ran 28 of 288 ticks at Western Slope, 35 at JP&Co, 241 at Situs. Directory refusals in the last 10 days: 4,914. Since Oct 23, new move-ins, contact changes and co-signers have reached Clara about one tick in nine at two customers. This is also why Andrew would see Western Slope's directory calls drop from ~285 to ~35 a day since Oct 23: a throttle, not a cut. Fix in progress (run occupancies before balances, or lower the reserve); it is a fix, so no switch, and it lands together with the daily directory so the directory count does not bounce back up.

What work orders at every minute actually buys today

Last 30 days of "new work order arrived" outcomes in the sync logs: 323 fetched detail with nobody paged (no handyman set up), 155 fetched detail with nobody paged (maintenance module off), 54 skipped (already closed or pre-onboarding backlog). Tech texts went only to Willows, our test property (1 sent, 3 held). No tenant acknowledgements were found in those logs. Fede kept work orders at every minute anyway; the day maintenance paging turns on at a customer is when this matters.

Proof, morning of Oct 28

One CloudWatch Logs Insights query on the sync Lambda's log group: requests per database per report per day (the Oct 1–22 baseline came from the same query), beside the budget-refusal and skipped-tick counts. Expected after all of tonight's merges reach production: rental applications ≤288 a day, tenant directory ≤5 a day, occupancies skipped ticks near 0, guest cards and work orders unchanged near 1,440.

Live in production: applications every 5 min (PR #23030, merged 03:56Z), the starved 5-minute tick fixed (PR #23050, merged 04:44Z), tenant directory once a day from a stored copy (PR #23055, merged 06:59Z). The sync logs show all three in effect by 09:00Z (3 AM Denver). Every number below is the CloudWatch per-request count for the two full hours 11:00–13:00Z, scaled to a day, against the Oct 1–22 daily average (Situs: against Oct 27, its Oct 1–22 window was partial).

Per report, Western Slope (calls/day, before → this morning): rental applications 1,444 → 288; tenant directory 285 → 0 since 08:00Z after one live pull per account at 07:00Z (the stored copy served 12 ticks an hour since); guest cards 1,423 → 1,440 and work orders 1,423 → 1,464, unchanged by design; rent roll 356 → 312; receipts, aged receivables, delinquency ~350 each → 312–336; lease dates 422 → 312; vacancy 261 → 288.

The starvation bug is gone. Our own budget refused 420 requests across the three accounts between midnight and 09:00Z, then 6 in 09–11Z and 4 in 11–13Z. Occupancies ticks skipped for throttling: 61 at Western Slope and 52 at JP&Co before 09:00Z, none after. New move-ins and contact changes reach Clara every 5 minutes again.

Why 24% and not the ~40% target: the remaining approved cuts (balance side reports hourly, lease dates) wait on Fede's two picks in section 8 and are not built. Guest cards and work orders, 43% of the total, stay at every minute by decision.

Proof query (CloudWatch Logs Insights, log group /aws/lambda/propflow-appfolio-sync-prod):

fields @timestamp
| filter @message like /GET https:\/\/[a-z0-9-]+\.appfolio\.com\/api\/v1\/reports\//
| parse @message /GET https:\/\/(?<db>[a-z0-9-]+)\.appfolio\.com\/api\/v1\/reports\/(?<report>[a-z_]+)\.json/
| stats count(*) as calls by db, report, bin(1h)

Refusals: filter account budget exhausted; skipped ticks: filter portfolio fetch throttled; directory reuse: filter tenant_directory from store / tenant_directory pulled live.

Fede gave the go after three side-effect investigations; both changes merged with no switch.

What changed

Side-effect studies

Live verification (17:46–19:00Z, CloudWatch + DynamoDB + production pages)

Expected tomorrow (per customer per day)

Estimates until the next CloudWatch count.

Side findings, not from today's change, for follow-up

• First-deploy burst of "unknown job type: lease_states" at 17:46 (schedule inputs updated 2.5 min after code; order them first next time).
• Collections "last paid" blank on most rows (live AppFolio lookup, pre-existing).
• Five accounts show aging on a $0 or negative balance.
• Two Camellia rows disagree with their own buckets.
• Situs stamp holds $3.06M owed across 123 occupancies (not checked).
• leasing:lease-terms-hydrate refused 228×/day at jpco.
• Situs payments post 5+ days late in AppFolio.