If a Visitor Can Read Your API Secret, So Can Everyone: Custom Next.js Sites That Book Into ServiceTitan From the Server

The client secret has to live somewhere

ServiceTitan's API accepts one kind of sign-in: the OAuth 2.0 client credentials grant, which its developer docs call "two-legged OAuth." A program trades a client ID and client secret for an access token that expires in 15 minutes, then sends that token on every call along with an app key in an ST-App-Key header. Each tenant gets its own client ID and secret. No refresh token is issued, and ServiceTitan recommends caching tokens.

Put those values in browser code and they belong to anyone who opens the developer tools. That is not a ServiceTitan weakness; it is how browsers work. So the first question about any website integration is where the secret sits and who can read it. On a Next.js site the answer is short. The Next.js documentation says "By default, environment variables are only available on the server," and a value reaches the browser only when a developer prefixes it with NEXT_PUBLIC_. ServiceTitan credentials never get that prefix.

The result is two separate conversations. The visitor's browser talks to the contractor's own website. The website's server talks to ServiceTitan. They never mix, which is the entire trick, and it is a dull trick, which is exactly what you want from anything that can put a request on the Calls screen.

The browser talks to your website. Your website talks to ServiceTitan. Nobody else gets the keys.

Script, relay or server: the three routes compared

Most contractor sites reach ServiceTitan by one of three routes. ServiceTitan's own Scheduling Pro installs as a script that opens an overlay. A plugin or automation tool relays form entries. Or the site's own server calls the API. Each has a place, and the table is meant to help you find yours, not to sell you the third column.

Scheduling Pro deserves a fair hearing, and our online booking page gives it one. ServiceTitan's product page says it shows "real-time availability based on your dispatch board," which a custom flow has to work to match. Nothing about Next.js rules the script out, either. A sensible site can run both: the scheduler for straight booking, server-side web forms for estimate requests, callbacks and emergencies.

Speed is part of the booking form

A homeowner with water on the kitchen floor does not wait for a page to finish thinking. A server-rendered Next.js page arrives as finished HTML, so the phone number, the service list and the request form are readable before any script runs. The submit button posts to a route on the same site, a short trip that does not wait for someone else's widget to load first.

Compare the usual stack on an older contractor site: a page builder, a slider, a chat bubble, a review carousel, two analytics tags and a form plugin, each fetching its own files. None is a villain alone. Together they make the company's hardest-working salesperson stand in a queue. The measured version of that argument is on our WordPress vs Next.js speed page, and how fast a site should load sets the targets.

Design control comes along at no extra charge. The booking steps use the site's own type, colors and buttons, so a customer moving from a drain cleaning page to the request form never feels handed to a different company. And because the booking page is plain HTML, search engines read it on the first fetch, like every service and town page on the site.

Every booking keeps the receipt from the ad that produced it

Here is where many website integrations quietly fail. The form arrives, the booking appears, and its source reads "website," which tells an owner about as much as "Earth." The ad click that produced it got lost somewhere between the landing page and the thank-you screen, and the monthly agency report fills the gap with clicks.

A server-side build keeps the click. When a visitor lands, the site records the landing page, the referrer and any click IDs or UTM tags in the address: gclid, gbraid, wbraid, fbclid, msclkid and the utm fields. Those match the WebSessionData object in ServiceTitan's Marketing Ads API, where landingPageUrl and referrerUrl are required and the rest are optional. After the booking is created, the server calls POST /web-booking-attributions, which ServiceTitan describes as "Attributes a web booking to a web session."

That pays off beyond the report. ServiceTitan's help center says its Google Ads integration, part of Marketing Pro Ads, has a conversion action named "ServiceTitan Integrated Bookings" for bookings with a GCLID sent through the "Marketing WebBookingAttributions API endpoint." Send the session and Google can learn which clicks became booked work. The whole chain is on our Google Ads conversion tracking page, phones have their own guide under call tracking, and the monthly view lives in marketing attribution.

From field map to first test booking

The build follows the method on our API integrations page, fitted to ServiceTitan's rules. Nothing touches the contractor's live board until bookings have gone through the integration environment, which ServiceTitan calls "the equivalent of the sandbox environment."

1. 1

   Agree the field map

   Each website field is matched to ServiceTitan's booking request. The schema requires source, name, summary, isFirstTimeClient and externalId; address, contacts, campaignId, businessUnitId, jobTypeId and priority are optional. The map is written down and the office signs off before any code.

2. 2

   The contractor's admin connects the app

   Under Settings > Integrations > API Application Access, the admin clicks "Connect New App," reviews the requested scopes and chooses Allow or Decline. A Booking Provider Tag comes first, and an account configuration must be on for bookings to reach the Calls screen. Whether API access is available at all depends on the contractor's ServiceTitan package.

3. 3

   Build against a copy of real data

   A ServiceTitan customer's admin can request integration environment access by emailing integrations@servicetitan.com. That environment holds a copy of the customer's production data, so test bookings look real without landing on the real board.

4. 4

   Validate, queue and retry

   The server route checks every submission and filters spam, writes it to a queue, and only then calls ServiceTitan. A failed send is retried, never dropped, and the externalId ties each booking to the exact submission in our logs.

5. 5

   Go live and keep watch

   Going live keeps the same app key and swaps in the production client ID, secret and URLs. After launch, Argus in Athena CMS watches for failing forms, broken links and slow pages.

What a custom site cannot promise

Selling a custom build by overselling it would be the web equivalent of the sticky note on the dispatcher's monitor: comforting, and wrong by Thursday. So here are the limits, plainly.

• ServiceTitan does not call the site back. The main API has no webhooks today; its developer FAQ says "V2 webhooks are currently being developed" and gives no date. Where the site needs data back, it asks on a schedule, within the published limit of "600 calls per 10 seconds per application per tenant."
• Availability has a horizon. The capacity endpoint returns "real time data about total capacity and availability to add jobs," but each request covers at most 14 days, a limit in force since November 13, 2025.
• Estimates stay in the office. A ServiceTitan help article says "Estimates cannot be created or booked directly from an external website into ServiceTitan." The site sends a booking or a lead form; the office turns it into a job and an estimate.
• A person still books the job. Bookings are inquiries on the Calls screen, where a customer service rep books each one into a job or dismisses it. Most offices consider that a feature.
• Access is the contractor's to grant. It depends on the ServiceTitan package and on the admin approving the app. ServiceTitan strictly prohibits "customer tunneling," asking a customer to create a user and register an app inside their own environment, and we do not do it.
• Someone has to look after it. A custom site is software. Our hosting and maintenance plans cover updates and monitoring, with no long contract.

Proof, prices and a fixed quote

This is work we have shipped. For Bleuwave Home Services, which does HVAC, plumbing, electrical and handyman work in the Phoenix metro, "an on-page assistant books straight into ServiceTitan," beside a request-a-callback form answered 24/7 by a real person. For HomeService WebApp, a contractor command center we redesigned, the API layer "syncs jobs and estimates bidirectionally with ServiceTitan." Both are in our work.

Custom builds and rebuilds are a fixed price from $1,750, and sites with a store, portal or web app start at $3,500. A site with online booking or an estimate flow is about $9,000 on our web design pricing page, and website financing at 0% splits that into $2,250 down and twelve payments of $562.50. Connecting a site you already own is quoted after a free review; a two-system connection is typically one to three weeks.

Trade builds: HVAC websites, plumbing websites and electrical websites. The roofing demo's booking page is a demonstration site we built, not client work. The full map of this section is on the ServiceTitan integration hub. Or call (210) 346-0848; we are in San Antonio, Texas, and work with businesses across the US.