A daily script that pulls the next 14 days for your buckets, separates confirmed from estimated, and writes a CSV plus a short digest.

Build a Python 3.12 CLI called `earnings_week.py` using only httpx and the standard library.

Data source: Veritas Data REST API, base https://api.veritasdata.dev, auth header `X-API-Key` read from env VERITAS_API_KEY. Respect the X-RateLimit-* response headers; sleep and retry once on 429.

Endpoint: GET /v1/calendar?from=YYYY-MM-DD&to=YYYY-MM-DD&status=&cap=&timing= (window max 120 days). Each event has ticker, name, market_cap_bucket, fiscal_period, report_date, timing (BMO before open, AMC after close, DURING, UNKNOWN), status, confidence (estimates only), call_time_et, webcast_url, source_url. Every key covers every company in the universe; a 400 on cap means a bad filter value, so print the message and continue.

Status rules, non-negotiable: `confirmed` = company announced it (cite source_url). `estimated` = projected from filing cadence; label it "est." everywhere and never present it as confirmed. `conflict` = sources disagree; flag it. `reported` = already out. `unknown` = no date; show "unknown", don't guess.

Behavior: default window today to today+14. Write earnings_week.csv (all fields) and print a digest grouped by day: confirmed first, then estimated with confidence, then conflicts. Flags: --from --to --cap --status --json. Include a README with setup and a sample run. Add pytest tests with a recorded JSON fixture; don't hit the live API in tests.

Polls the changes feed, remembers where it left off, and messages you when a date is confirmed, moved, or goes into conflict.

Build a small alerting service in [Python or TypeScript, your choice] that watches earnings-date changes from Veritas Data and posts to a Slack incoming webhook (URL from env SLACK_WEBHOOK_URL).

API: base https://api.veritasdata.dev, header X-API-Key from env VERITAS_API_KEY. Endpoint GET /v1/changes?since=ISO8601&ticker= returns changes with changed_at, ticker, name, fiscal_period, old_date, new_date, old_status, new_status, source_url, current_status, current_report_date. Every company in the universe is returned.

Requirements: persist the last `changed_at` seen in a local JSON file so restarts never miss or repeat a change. Poll every 15 minutes during US market weekdays 06:00 to 20:00 ET, hourly otherwise. Optional watchlist file (one ticker per line); if present, only alert on those. Message format: "[CONFIRMED] CROX Q3 FY2026 now 2026-11-05 AMC (was est. 2026-11-04). Source: "; use [MOVED], [CONFLICT], [REPORTED] similarly. Never describe an `estimated` date as confirmed; when new_status is estimated, prefix "est.". Handle 429 with backoff. Add a --once flag for cron use and a Dockerfile. Tests with fixtures, no live calls.

Uses our history of actual report dates as the event anchors and your own price data to measure what happened around them. Paper research, not a trading system.

Build a Python research notebook or script for an earnings event study. I will supply daily OHLC prices as a CSV (ticker, date, open, high, low, close, volume); do not fetch prices from anywhere.

Event dates come from Veritas Data: base https://api.veritasdata.dev, header X-API-Key from env VERITAS_API_KEY. GET /v1/history/{ticker}?limit=40 returns past releases with report_date, timing (BMO/AMC/DURING/UNKNOWN), fiscal_period, days_after_period_end and the 8-K source_url. Only `reported` events are actual dates; use those as anchors. Respect rate limits; cache responses to disk so reruns don't spend API calls.

Method: for each ticker and event, define day 0 as the first trading session that could react: the report date itself for BMO, the next session for AMC, and skip UNKNOWN timing (count how many were skipped). Compute returns for windows [-5,-1], [0], [0,+1], [+1,+5] in both raw and market-adjusted form (I'll provide an index CSV in the same format). Output: per-event table, per-ticker summary (mean, median, hit rate, n), and a pooled summary with simple bootstrap confidence intervals. Plot the average cumulative return path from -5 to +5.

Be explicit in the README that this is descriptive research on past events, survivorship and look-ahead caveats apply, and nothing here is a trading recommendation. Tests on a synthetic price series.

Feed it your holdings; get back who reports when, which dates are only estimates, and what's inside the next 7 days.

Write a command-line tool `holdings_earnings` that reads a CSV of my positions (ticker, shares, optional cost_basis) and reports upcoming earnings for each.

Data: Veritas Data API, base https://api.veritasdata.dev, header X-API-Key from env VERITAS_API_KEY. For each ticker call GET /v1/next/{ticker}; the response has fiscal_period, report_date, timing, status (confirmed | estimated | conflict | reported | unknown), confidence, call_time_et, webcast_url, source_url. A 404 means the ticker is outside the covered universe: show "not covered" and keep going. Cache results for 6 hours to save calls.

Output a table sorted by report_date: ticker, date, BMO/AMC, status, confidence (estimates only), days until, source link. Mark estimated dates with "est." and a note that they are projections from filing cadence, not company confirmations. Then print three lists: reporting in the next 7 days, dates in conflict, and holdings with status unknown. Flags: --days N, --json, --only-confirmed. Include tests with fixtures and a README.

Connect the MCP server once, then these prompts work in any chat. No code.

Setup (once): add this MCP server to your client.
{ "type": "http", "url": "https://api.veritasdata.dev/mcp", "headers": { "X-API-Key": "YOUR_KEY" } }
Tools: get_next_earnings, list_earnings, get_date_changes, get_earnings_history.

Then ask:
"Using Veritas, list every company reporting between next Monday and Friday. Group confirmed dates separately from estimated ones, show BMO/AMC, and give me the source link for each confirmed date."

"Which earnings dates changed in the last 48 hours? For each, say the old date, the new date, whether it's now confirmed or still estimated, and cite the source."

"For CROX, show the last 12 report dates with timing and the days after quarter end. Is there a pattern in weekday or lag? Then show the current estimate and its confidence, and say clearly that it is an estimate."

House rule for the assistant: never present an `estimated` date as confirmed, always relay `status` and `source_url`, and if a company is outside the covered universe say so.

Tracks a list of names through the quarter: when each moved from estimated to confirmed, how far the confirmed date landed from the estimate, and who still hasn't announced.

Build `confirmation_tracker.py`: given a tickers file, track each company's next earnings date through the quarter and measure how our estimates resolve.

API: Veritas Data, base https://api.veritasdata.dev, header X-API-Key from env VERITAS_API_KEY. Use GET /v1/next/{ticker} daily (cache per day) and GET /v1/changes?since= to catch transitions between runs. Fields: report_date, status (confirmed | estimated | conflict | reported | unknown), confidence, source_url, and for changes old_date/new_date/old_status/new_status.

Store a SQLite history of every (ticker, date_seen, report_date, status, confidence). Report: for each ticker, the first estimated date, the date it became confirmed, the confirmed date, and the difference in days; the share still estimated; conflicts; unknowns. Print a summary and write report.csv. Make the estimated/confirmed distinction visually unmistakable in output. Rate-limit aware; tests with fixtures; README with a cron example. No trading logic.