Integrate with what you already run

Most firms PaxExact is built for already run something: a CRM, a claim-management platform, an accounting system, or all three. Asking them to abandon that system to adopt an estimating tool is a bad trade, and it isn't the trade PaxExact is designed to ask for. The intent is for PaxExact to be the estimate-and-evidence system of record — the place where scope, pricing, and documentation are traced and approved — while the systems a firm already trusts for accounts, pipeline, and billing stay exactly where they are.

That principle splits customers into two paths. A firm with an existing platform integrates PaxExact into it, on the API and connector foundation this page describes. A firm without one can eventually run its whole operation inside PaxExact's own Back Office module instead. This page covers the first path — connecting PaxExact to a system you already run.

PaxExact's REST API is deployed and answering in production. It is BETA in the sense this site uses that label: usable, with a limited scope. Keys are issued by PaxExact staff by arrangement rather than through self-serve signup, and the API covers estimates, rooms, line items, and pricing lookup — there are no webhooks or connectors yet.

The API is organized around organization-scoped keys that carry their environment in the key itself — a live key begins pxk_live_ and a sandbox key begins pxk_test_ — so sandbox activity can never be mistaken for live data. Every authenticated call reports its own rate-limit headroom (a 120-requests-per-minute default, via X-RateLimit-* headers) and carries a request id for tracing a specific call later. An API-created estimate can also carry external_reference, your own claim or job reference, so a record on your side and a record on PaxExact's side can be reconciled by that shared value — the field is free text; a structured, two-way linkage is planned rather than built.

Today, PaxExact's webhook infrastructure runs in one direction only: it receives events from a vendor (the sandboxed pricing feed described on the pricing-intelligence page). Nothing currently notifies a customer's own system when something changes on a PaxExact case.

Outbound webhooks are designed to close that gap: signed event notifications your systems can subscribe to, so a change on a PaxExact case reaches you without polling the API for it. The events under design include an estimate being created, approved, or exported, and a case's status changing. This is architecture, not a shipped feature — treat it as not built until this page's capability status changes.

A Salesforce connector is on the roadmap. It is not built — no Salesforce-specific code exists in PaxExact today. The same is true of connectors for other CRMs and claim-management platforms: none exist yet. What both would share, once built, is the same foundation described above — the developer API for pulling and pushing records, and outbound webhooks for being notified of changes — rather than a separate, one-off integration mechanism per vendor.

The object types a connector or API integration is designed to keep in step cover a case end to end: cases and claims, accounts and contacts, properties, estimates, documents and evidence, status, and assignments. None of this cross-system synchronization is built yet — it describes the intended scope of the integration layer, not a current feature.

The same foundation is meant to reach downstream accounting and workflow systems eventually, so an approved estimate's data doesn't have to be re-keyed into billing or operations software by hand. No specific downstream system is built or named as a partner today; this is a stated architectural direction, not an available connector.

The only export that exists in production today is the case-file PDF: an approved case exports as a defensible document, described on the case-file page. Bulk import and export of estimates, contacts, and properties in an open format, and a full organization data export on request, are both planned rather than built. The commitment behind both is the same one PaxExact applies to the PDF export already: your organization's data should never be trapped in a format only PaxExact can read.