What a daily report API should expose
Daily reports become more valuable when they are structured as data, not just PDF summaries. A daily report API should make each field input available by project, date, status, activity, and cost category.
- Report header: project, date, shift, status, weather, submitter
- Labor entries: worker, trade, regular hours, overtime hours, activity code
- Equipment entries: equipment, hours used, idle time, activity code
- Material entries: material, quantity, unit, PO line, activity code
- Subcontractor entries: vendor, PO/work order, labor hours, cost, activity code
- Production entries: quantity installed, unit, location, activity code
- Notes, photos, documents, and work orders as supporting context
Read endpoints before write endpoints
The safest first API for daily reports is read-first. External systems can consume committed reports, cost entries, and production quantities without changing the field workflow. Write APIs are useful later, but they require stricter idempotency, validation, permission scopes, and review/commit rules.
GET /api/v1/projects/{project_id}/daily-reports/{date} should
return report status plus committed labor, equipment, material,
subcontractor, production, notes, photos, and early signals for that day.
Status matters
Construction daily reports usually include draft, pending, approved, and committed data. A public API should be explicit about what it returns. For reporting and integration workflows, committed entries are usually the safest default because they represent reviewed project records.
How TCC approaches daily report data
TCC captures daily labor, equipment, material, subcontractor, production, notes, photos, weather, and work order context. The product already treats daily reporting as a structured execution dataset, which makes it a strong foundation for Power BI, cost exports, and future API access.