How to Connect Your Website to ServiceTitan, Jobber, or Housecall Pro

The three ways a website actually talks to your field software

Strip away the marketing language and there are exactly three mechanisms a contractor website uses to hand a lead or a booking to ServiceTitan, Jobber, or Housecall Pro. Knowing which one you're on tells you what's possible and what's going to break.

• Embedded widget (iframe or JS snippet). The platform hosts the booking flow, your site just frames it in. Jobber's Client Hub booking widget and Housecall Pro's online booking widget both work this way. Fast to install, but you're limited to the platform's layout, fields, and availability logic. Your site's speed and design stop the moment the widget loads its own script.
• Form-post to webhook or Zap. Your site's contact or estimate-request form submits to your own backend or a form service, which then fires a webhook (or a Zapier/Make automation) that creates a lead, job, or estimate inside the CRM. This is the most common ServiceTitan pattern, since ServiceTitan doesn't publish a simple embeddable widget the way Jobber and Housecall Pro do.
• Direct API integration. Your site (or a backend service behind it) calls the platform's REST API directly, using OAuth credentials, to create customers, jobs, or estimate requests, and can also pull data back (technician availability, job status) to show on the site. This is the heaviest lift and the only option that lets a booking widget feel truly native to your site's design instead of looking bolted on.

All three approaches coexist on real contractor sites. A shop might use Jobber's widget for simple booking and a separate webhook for a custom estimate-request form that captures more detail than the widget allows. The question isn't “which one is correct.” It's which one matches what you're actually trying to capture, and whether your current site can even support it.

One thing that trips up a lot of owners: a widget or webhook is not the same thing as “my website is connected to my CRM.” Connected, done right, means every form on the site, the phone number, the click-to-text, and the booking flow all land in the same place with the same tagging, so nothing falls through a gap between the site and the office. A lot of “connected” contractor sites are really just one form pointed at one Zap, with everything else still going to an inbox nobody checks on weekends.

ServiceTitan: what it will and won't let a website do

ServiceTitan is built for large field-service operations running dispatch, techs, and payroll through one system, and its web-facing tooling reflects that. There's no plug-and-play embeddable booking widget shipped the way Jobber and Housecall Pro offer one. What ServiceTitan gives you instead is a real API (ServiceTitan calls their developer platform the “ST Developer Portal”) with endpoints for creating leads, booking appointments, and pulling job or customer data, gated behind OAuth 2.0 and an approved integration.

In practice, a ServiceTitan connection on a contractor website usually looks like one of these:

• Lead capture only. Your site's forms post to a webhook that creates a “lead” or “call booking” object in ServiceTitan through the API, which then shows up in the CSR queue like any inbound call. No live availability shown on the site, just a clean handoff.
• Live scheduling via API. A more built-out integration pulls real appointment windows from ServiceTitan's scheduling engine and lets the homeowner pick a slot on your site, which then books directly into dispatch. This takes real engineering, since you're calling authenticated endpoints and handling token refresh, not dropping in a script tag.
• Middleware (Zapier, Make, custom backend). Most shops route through an automation platform rather than hand-rolling direct API calls, trading a bit of latency and monthly cost for a much shorter build. This is the fastest path to “the form talks to ServiceTitan” without writing an OAuth flow from scratch.

The practical takeaway: if a vendor tells you they'll “connect your site to ServiceTitan” in an afternoon with a copy-paste widget, be skeptical. There isn't one. A real ServiceTitan integration means either API work or a webhook-to-Zap bridge, and the honest timeline runs longer than a Jobber or Housecall Pro hookup. Budget for it accordingly, and ask exactly which of the three patterns above the build will use before you sign anything.

Jobber and Housecall Pro: the widget path

Jobber and Housecall Pro both took the opposite approach from ServiceTitan: they ship a ready-made booking widget meant to be dropped onto a website in minutes. That makes them the friendlier of the three to connect to, especially for a smaller shop that wants online booking live fast without a development project.

Jobber's booking widget works through the Client Hub: you get an embeddable form or a hosted booking page, configurable for which services show, what info you collect, and how requests route into Jobber as a new client and request. It's a script/iframe embed, so installing it is closer to adding a chat widget than building an integration. The tradeoff is design control. The widget renders in Jobber's own styling and flow, so it will always look like a widget bolted onto the page rather than a piece of the site itself, no matter how custom the rest of your build is.

Housecall Pro's online booking works the same way in spirit: an embeddable widget or a hosted booking link that creates a job or estimate request directly in the Housecall Pro account. Both platforms also expose APIs (Housecall Pro has a public API, Jobber has a GraphQL API) for shops that want to go further than the stock widget, most often to build a custom-styled booking flow that matches the site's design instead of looking like an off-the-shelf plugin, or to sync data the widget doesn't expose (technician-level availability, custom job types, service-area logic).

Here's the tradeoff most owners don't see coming until it's live: the stock widget is the fastest way to get “online booking” working, but it's also the thing most likely to make a custom-built site suddenly look like a template site again, because for those few seconds the homeowner is inside someone else's box, not yours. Where it matters for conversion, it can be worth the extra build time to skin the flow through the API rather than accept the stock look. Where it doesn't (a simple “request a quote” form, no live scheduling needed), the stock widget is the right call and there's no reason to over-engineer it.

Webhooks vs API: what's the real difference for a contractor site

These two terms get used almost interchangeably by salespeople, but they're doing different jobs, and knowing which one your site needs keeps you from paying for engineering you don't need, or worse, ending up with a form that quietly fails.

For the large majority of contractor websites, a webhook is enough. You need the homeowner's form submission to become a lead or job request inside ServiceTitan, Jobber, or Housecall Pro without anyone re-typing it, and you need it to happen reliably, with a clear error path if it fails (the number one silent failure on contractor sites: the webhook breaks after a platform updates its API, the form still “submits” from the homeowner's side, and nobody in the office notices leads have stopped arriving for two weeks).

Full API integration earns its cost when you want the website itself to behave like part of the CRM, showing real tech availability, letting a customer reschedule an existing job, or pulling job history into a client portal. That's a real build, not an afternoon task, and it should be scoped and quoted as one. Most shops don't need it on day one. Get reliable lead capture wired first, prove it holds up, then decide if live scheduling is worth the heavier lift.

What actually breaks these integrations (and how to catch it)

The wiring diagram looks clean in a sales deck. In production, a handful of specific failure points account for almost every “our leads stopped coming in” call we get from contractors who already have some kind of connection in place.

1. The webhook silently fails. An API version deprecates, a field gets renamed, an auth token expires, and the form keeps showing “thank you” to the homeowner while nothing lands in the CRM. Without monitoring or a fallback notification (an email copy of every submission, at minimum), this can run for weeks before anyone notices bookings are down.
2. Slow forms lose the lead before it ever reaches the wiring. A widget or a heavy JS form on a page that takes four or five seconds to load will bleed homeowners before they ever hit submit. The integration can be flawless and it won't matter if the page around it is slow. This is the build-quality half of the problem, and it's the half most agencies selling “CRM integration” never touch.
3. Mismatched fields. The site's form asks for “best time to reach you” and the CRM has no field for it, so it either drops or dumps into a generic notes field nobody reads. Map every field on the intake form to a specific field in the CRM before launch, not after.
4. Duplicate leads from double-submission. No submit-button lock, and an eager homeowner on a slow connection clicks twice, creating two jobs in the CRM that a CSR now has to notice and merge by hand.
5. Spam getting through as a “job.” No bot protection on the form means the CRM fills with junk leads that look real enough to require manual review, burning staff time on the office side, not the marketing side.

None of these are exotic problems. They're the ordinary failure modes of gluing a form to an API, and every one of them is preventable with the right build: server-side field validation, an error-path notification if the CRM push fails, honeypot or Turnstile spam protection, and a submit lock. It is the plumbing, not the platform, that determines whether the integration is trustworthy six months from now.

What to ask before you pay someone to build this

If you're hiring out a website rebuild or an integration project, the questions below separate a shop that has actually built these connections from one that's going to figure it out on your invoice.

• Which of the three patterns are you building? Widget, webhook, or full API. If they can't answer this specifically for your platform (especially ServiceTitan, where there is no stock widget), that's a red flag.
• What happens if the connection fails? Ask for the fallback. A serious build includes an error notification (email or Slack alert) the moment a CRM push fails, so a broken webhook gets caught in hours, not months.
• Who owns the credentials? API keys and OAuth tokens for ServiceTitan, Jobber, or Housecall Pro should live in your accounts, not buried in a developer's personal Zapier login that walks out the door if you part ways.
• Is this a one-time build or a maintained connection? Platforms update their APIs. A webhook built two years ago against an old API version can quietly stop working. Ask whether updates are included or billed separately.
• Does the rest of the site actually load fast? A perfectly wired integration bolted onto a slow, plugin-heavy site still loses leads at the door. The two problems get sold separately by agencies that only do one of them. They shouldn't be solved separately.

We build these connections as part of hand-coded contractor sites, hosted on your own Cloudflare account, with the credentials and the codebase handed to you, not held hostage on someone else's server. Whether it's a Jobber widget skinned to match the site, a webhook wired into ServiceTitan with real failure alerts, or a Housecall Pro booking flow that doesn't look like a plugin dropped onto a template, the integration only holds up if the site around it is built to hold up. That is the whole job here: the site, wired right, owned by you.