How to Set Up Patchment with Housecall Pro: Connect, Import, and Day-of Division of Labor

If Housecall Pro is where your jobs, customers, and schedule live, an AI front office is only useful if it writes into that account rather than building a second one beside it. This guide covers how Patchment (that's us) connects to Housecall Pro, what happens to your existing history on connect, and the one behaviour change that surprises people most: once Housecall Pro is connected, Patchment stops texting your technicians.

Quick answer: Patchment connects to Housecall Pro with an API key you generate and paste in, not an OAuth redirect. On connect it enqueues a one-time import of your existing Housecall Pro data so returning customers are recognised on the first call. From then on, your technicians keep using the Housecall Pro app exactly as they do today, and their status taps arrive at Patchment as webhooks and trigger the customer-facing updates. Patchment writes jobs and requests back into Housecall Pro through a narrow set of calls that only ever run as an approved action.

Connecting: bring your own API key

The Housecall Pro connection is a bring-your-own-key integration. You generate an API key in your Housecall Pro account and paste it into Patchment's Integrations page. This is a deliberate difference from the Jobber integration, which uses an OAuth authorization flow.

The practical differences are worth knowing before you start. There is no redirect URI to register and no app to authorize, so setup is a single paste rather than a browser round trip. In exchange, the key is yours to rotate: if you regenerate it in Housecall Pro, you reconnect in Patchment. The credential is stored sealed rather than in plain text, and the same treatment applies to the webhook signing secret.

Disconnecting removes the stored credential for your organization. It does not reach into Housecall Pro and undo work that was already written there.

What the historical import does, and how you know it worked

Connecting enqueues a one-time backfill of your existing Housecall Pro data. This is what lets Patchment recognise a returning customer on the very first call after setup instead of treating everyone as new for the first few weeks.

The part worth calling out is the failure reporting, because it is the thing most integrations get wrong. A backfill that failed and an account that simply has no data yet both look identical from the outside: an empty catalog. Patchment records a completion or failure outcome for the import and the Integrations page reads the most recent one, so the page can tell you in plain English that the import finished or that it did not, rather than showing an importing spinner forever.

That covers the case where the import itself fails. It also covers the narrower case where the import never got queued at all, which is otherwise invisible: that path records the same failure shape so the page reports it immediately instead of waiting on something that will never run.

If the page says the import failed, reconnect. Don't assume an empty customer list means an empty account.

Day-of division of labor: Patchment stops texting your techs

This is the design decision to understand before go-live, because it changes what your technicians experience.

For organizations without a connected field-service platform, Patchment runs the technician side over SMS. Technicians text short commands to move a job along and Patchment keeps the customer informed from those messages.

For Housecall Pro connected organizations, that stops. Your technicians keep using the Housecall Pro app, which is the timeline of record for their side of the job. When a technician taps a status in that app, the tap arrives at Patchment as a webhook, and that is what wakes the system to notify the customer.

The reasoning is simple. Asking a technician to tap a status in one app and also answer a text from another system is asking them to do the same job twice, and the second one is the one they will skip. Whichever system they actually use becomes the truth, and for a Housecall Pro shop that is Housecall Pro. So Patchment reads from it rather than competing with it. For an HVAC crew already living in the Housecall Pro app all day, this is the difference between an integration they notice and one they do not.

Four job status topics carry those taps. For your crew, the change at go-live is nothing at all: they keep working the way they already do. What changes is that customers start hearing about it.

Webhooks, redeliveries, and duplicate updates

Two details matter for reliability, and both are handled rather than left to chance.

Incoming webhooks are signature verified against the secret stored for your organization, so a request that did not come from Housecall Pro does not move your jobs.

Housecall Pro also redelivers webhooks. Without care, a redelivered status tap would append a second identical entry to a job's timeline and could trigger a duplicate customer message. Patchment checks the job's most recent day-of update before appending a new one, and takes a lock on the job row for the read and the append so two simultaneous redeliveries cannot both decide they are first. The check is deliberately narrow, looking at the most recent update rather than banning repeats outright, so a legitimate status change back to an earlier state, such as a re-dispatch after a job was already started, is still recorded.

What Patchment writes back

Writes into Housecall Pro are confined to a single narrow module, and those calls only run as an executed action, which means they are subject to the autonomy settings you configure rather than firing as a side effect of a conversation. If you have not granted the system permission to create a job, it proposes one and waits for you.

Two pushes exist beyond creating work: reassigning a technician and pushing a reschedule. Both are live-validated for Housecall Pro, and both wait for a person. A reassignment is pushed only when you approve the proposed change, and a reschedule has no automatic setting to turn on.

Job and request field shapes follow the published Housecall Pro API. Treat your own test booking as the acceptance check for your account's configuration rather than assuming every field maps the way you expect, and confirm the first few jobs land correctly before you forward your main line.

A short go-live sequence

• Generate a Housecall Pro API key and connect it in Patchment.
• Wait for the Integrations page to confirm the historical import completed. If it reports a failure, reconnect before continuing.
• Place a test call as a new customer, then confirm the request and the job appear correctly in Housecall Pro.
• Place a second test call from a number belonging to an existing Housecall Pro customer, and confirm they are recognised rather than created again.
• Have a technician tap a status in the Housecall Pro app, then confirm the customer receives the corresponding update.
• Only then forward your main business number.

Consent for the customer-facing messages is a separate prerequisite with its own rules. See our guide to SMS consent in field-service booking before the first live text goes out. For emergency-specific routing across either platform, see automating emergency dispatch.