← All guides

Why your estimating API returns the customer record, not the estimate

Your team connected the estimating tool. Slack got the screenshot. Then someone asked for line items, assemblies, and the basis of estimate. What came back was a job name, an address, and a customer ID.

The job of this page

Stop celebrating the wrong integration. Before you buy more connectors or bolt AI on top, define the estimate object you actually need and map what the tool can export today.

Integration theater

Precon teams get sold on “we have an API.” Ops hears “the systems talk.” IT wires a webhook. Leadership checks the box.

What usually ships is a thin customer or job record: name, address, job number, maybe a bid status. Useful for CRM. Useless for pricing the work or handing it to the field.

AI on top of that cannot invent assemblies you never exported. It can only summarize the wrong object with more confidence.

What people actually need from estimating systems

Not another dashboard. The estimate as a structured object that survives award:

• Quantities and units. What was takeoff, what was assumed, what still floats.
• Assemblies and cost codes. How the price was built, not just the rolled-up total.
• Basis of estimate. Productivity, labor rates, markups, inclusions, exclusions. Written.
• Alternates and options. What was priced, selected, or left for owner decision.
• Risk notes. The few items that blow the job if ignored, with an owner on each.

If your export cannot carry those fields, you do not have an estimating integration. You have a customer sync with a fancy name.

One concrete picture

Mid-market GC. IT connects the estimating platform to the ops system. Demo day shows job name, address, and bid amount flowing cleanly. Everyone claps.

Week two, the PM asks for the assembly that drove temporary power, the productivity assumed on hanging drywall, and which alternate the owner verbally picked. The API returns the customer record again. Estimating still emails a spreadsheet. Ops still rebuilds the job in their head.

Same company, next quarter: they write a one-page “estimate object” before buying more middleware. They map each field to what the tool actually exports (native report, CSV, PDF parse, or manual). Half the wishlist is not in the API. They stop calling that a product gap they will “AI later” and start owning a handoff path that includes the missing pieces.

Scene is an illustrative pattern, not a named client case study.

What “done” looks like

You can answer, in writing: which estimate fields matter for handoff, which ones the tool exports today, and who owns the gaps. No more “we connected the API” as a proxy for “ops can run the job.”

Buy integration when it moves those fields. Until then, treat customer-record sync as what it is: CRM plumbing, not estimating.