Buildxact API Guide for Builders and Remodelers

One-line verdict: A strong, modern API with signed webhooks and a published rate limit — after Buildxact approves your subscription request. Openness: 4 / 5 — rated 4 because Buildxact documents a full REST API with OAuth tokens, subscription keys, named webhook events, and a stated rate limit, held back from 5 by the team-approval gate on keys.

The connection that works

Rung 1 — Direct connection. Buildxact’s developer portal is the full reference for its current API (v3; the portal warns v1 and v2 deprecate soon — build on v3). Access runs on two credentials at once for your own company’s connection: a subscription key, requested on the developer portal — Buildxact uses your company name to verify you’re a customer or partner, and the request goes “through to our team for approval” before primary and secondary keys appear on your profile — plus a login token: an API Key generated inside the app exchanges for a short-lived bearer token (with a long-lived refresh token), and the subscription key rides on every request. Staging gets its own separate keys.

For apps other companies install, the pattern is proper delegated OAuth: you register with Buildxact support, receive a Client ID and Secret, and each customer approves access on a consent screen showing the scopes requested (Catalogues, Leads, and the like). Apps registered after July 14, 2026 sit in a stricter mode — PKCE mandatory, authorization-code and refresh grants only. Rate limits are published: 100 requests within a 30-second period, with an HTTP 429 past that.

Verified operations: Leads — create (documented step-by-step for website lead capture), Clients and their Contacts — create (required steps before a lead can be created), Catalogues — full read/write including items and imports, and Jobs — queryable through the API’s OData filtering, with the portal’s own example searching jobs by client name. An Estimate create is referenced in the v3 migration notes; endpoint-level estimate access is flagged below.

Webhooks: documented and taken seriously — register them in the app, payloads are signed with a secret you validate, failed deliveries retry three times (5 minutes, 30 minutes, 4 hours), and a hook that fails too often disables itself. Named standard events include Estimate Accepted, Lead Created, and Lead Updated; the complete list appears in-app during registration, and some events are exclusive to Merchant and Manufacturer plans.

Bridge apps: no Buildxact app was found on Zapier or Make. The direct API carries everything; there is no bridge rung.

Can automate

• Website lead capture, for real — the vendor documents the whole chain: create the client, create the contact, create the lead — so a form fill becomes a Buildxact lead without human hands.
• Estimate-accepted alerts — a documented webhook event means the moment a client accepts, your follow-up, scheduling, or deposit workflow can start.
• Supplier catalogue upkeep — catalogues and items are fully readable and writable, including imports, so price-book maintenance can be automated instead of re-typed.
• Job lookups across tools — OData querying lets your other systems find and read jobs by client and criteria.

Can’t automate

• Invoices and payments — UNVERIFIED. No endpoint-level invoice or payment access, read or write, was verified in the vendor documentation we read. Invoice-chase builds cannot rest on this API yet.
• Estimate read, and endpoint-level estimate create — UNVERIFIED. A create is referenced in migration notes and “Estimate Accepted” is a documented webhook event, but the endpoint reference itself is portal-rendered and wasn’t text-verified in our pass.
• Lead and client reads, endpoint by endpoint — UNVERIFIED. The creates are documented; don’t infer the reads from them.
• Job creation or updates — UNVERIFIED. Jobs are documented as queryable; writes were not verified.
• The full webhook catalog — only three standard events are named in the public docs; the rest shows in-app, and some events are Merchant/Manufacturer-only.

Hidden gate: Buildxact has to approve your subscription request before you get a key — and you need that key plus a login token on every single call. It’s a short gate, but it sits in front of everything, including your timeline.

Build fit — what this platform supports well

• Speed-to-Lead — strong fit: the website-to-lead chain is documented by the vendor itself, and Lead Created fires a webhook.
• Estimate Follow-Up — the acceptance signal is real (Estimate Accepted webhook), so post-acceptance workflows are buildable; pre-acceptance chasing keyed off estimate records is UNVERIFIED.
• Missed-Call / After-Hours Capture — works: a captured call becomes a client, contact, and lead through the documented creates.
• Invoice Chase / AR — not on this API: invoices are UNVERIFIED; the chase runs on our messaging layer.
• Review Engine — like every platform here, Buildxact has no verified reviews API, so the review ask runs on our system triggered by a job-completion signal.

What this means for your shop

If you build or remodel on Buildxact, your front end is genuinely open: leads in, acceptance signals out, catalogues maintained — once the approval lands. Keep expectations where the docs put them: money records aren’t in the verified surface, and the full webhook list lives inside the app. Ask for the subscription approval first, and read any quote against the portal, not the pitch.