Earnings Calendar Scraping Notes (Legal + Fragile)
Posted: Sat Sep 05, 2026 9:30 am
Scrapers break. Terms of service exist. Treat calendar automation as **convenience**, not a business-critical feed, unless you pay for a licensed API.
I prototype scrapers for personal research. I do not bet size on a CSS selector that can vanish on a Thursday. Learned that when a "confirmed" time silently flipped and I still had working orders like an idiot.
### Practical approach
1. Prefer **official IR pages** + licensed calendar APIs for anything you size on.
2. If you prototype scrapers: throttle hard, cache aggressively, expect HTML to change the week you need it.
3. Store: ticker, period, date, bmo/amc flag, confirmed vs estimated, source URL, retrieved_at.
### Schema worth keeping
### Fragility checklist (conversational version of what I tick)
### Scalper-specific use
Earnings week ≠ "fade everything." It means: know **who reports tonight**, cut size into binary events, and don't leave working orders through prints you didn't plan for.
Not posting site-specific selectors on purpose — they rot and encourage reckless scraping. Build against sources you're allowed to use.
What calendar source do you trust enough to size on — API, IR pages, or something else?
Anyone automate confirmed vs estimated and still got burned by a time change?
How do you alert yourself when the parser fails instead of going silent?
DST bugs — war story? I've got one if you don't.
I prototype scrapers for personal research. I do not bet size on a CSS selector that can vanish on a Thursday. Learned that when a "confirmed" time silently flipped and I still had working orders like an idiot.
### Practical approach
1. Prefer **official IR pages** + licensed calendar APIs for anything you size on.
2. If you prototype scrapers: throttle hard, cache aggressively, expect HTML to change the week you need it.
3. Store: ticker, period, date, bmo/amc flag, confirmed vs estimated, source URL, retrieved_at.
### Schema worth keeping
Code: Select all
ticker,period,date_et,session_flag,status,eps_est,rev_est,source_url,retrieved_at_et
Code: Select all
[ ] User-Agent honest / not pretending to be Googlebot
[ ] 1 request / N seconds
[ ] Parse fails → alert, don't silently trade empty calendar
[ ] DST / ET conversion tested around spring/fall
[ ] Confirmed vs expected labeled in UI
Earnings week ≠ "fade everything." It means: know **who reports tonight**, cut size into binary events, and don't leave working orders through prints you didn't plan for.
Not posting site-specific selectors on purpose — they rot and encourage reckless scraping. Build against sources you're allowed to use.
What calendar source do you trust enough to size on — API, IR pages, or something else?
Anyone automate confirmed vs estimated and still got burned by a time change?
How do you alert yourself when the parser fails instead of going silent?
DST bugs — war story? I've got one if you don't.