An API is a set of rules that lets one program ask another for data or actions. A REST API, the most common style, uses web requests: GET /projects/24-118/rfis to list RFIs, or POST /change-orders to create one. APIs need authentication (keys or tokens) and permissions, so a connected tool sees only what it’s allowed to.
Why it matters
Construction companies run many tools: estimating, scheduling, project management, accounting, payroll, BI. Without APIs, data moves by CSV export, email and re-typing, which is slow and error-prone. A good API lets you connect tools, automate reports and build your own workflows on your own data.
Worked example
Illustrative: a reporting script calls an API each morning to pull open RFIs for Job #24-118, filters for overdue items, and posts the list to the project team. On a day with 23 open RFIs, it would flag the 4 overdue ones, including any that are holding up a change order, like RFI-212 before CO #14 was priced.
Common mistakes
- Assuming “has an API” means every field and action is available; many APIs are read-only or partial.
- Sharing one admin API key across many integrations, with no way to trace or revoke access.
- Ignoring rate limits and pagination, then wondering why data is missing.
How os.construction handles it
A public API is planned, not available yet. We’re designing it alongside the data core with founding contractors, and any docs we publish will be labeled Preview.