You’re running a service business with multiple locations. Or maybe you’re an agency managing WordPress sites for a dozen Jobber clients. Either way, you’ve got the same problem: separate WordPress installs everywhere, each one needing its own updates, its own backups, its own admin login. Plugin breaks on one site, and you’re fixing it six times over. Domain management is a nightmare. You’re constantly duplicating work.

I know, original problem right? But here’s the thing—most people just accept this mess. You don’t have to.

WordPress Multisite changes the game. One dashboard. One codebase to update. One place to manage everything. And here’s the kicker: each site still gets its own Jobber connection, its own clients, its own independent booking system. You’re not sacrificing control for convenience.

This isn’t a technical deep-dive into Multisite architecture (though we’ll get there). It’s about whether this approach actually makes sense for your operation, and if it does, how to set it up so each site runs independently while you manage everything centrally.

When Multisite Makes Sense (And When It Doesn’t)

Real talk: Multisite is more complex than a single WordPress install. It’s not a casual decision. But it’s the right call if you’re in one of these situations:

Multiple branded service areas: You’re an HVAC company with locations in three cities, each with its own website and Jobber account. Your franchisees each want their own domain, their own brand feel, but they’re all part of the same company infrastructure.

Agency managing multiple clients: You’re a WordPress development shop, and half your clients are service businesses using Jobber. Instead of hosting their sites separately, you manage them all in one Multisite network. One codebase, one admin panel, synchronized updates.

Shared branding with location-specific content: A plumbing company with “HQ” and regional offices. Core brand assets, templates, and Jobber workflows are shared. But each location markets its own service areas, has location-specific testimonials, and books jobs through its own Jobber account.

You don’t want Multisite if:

You’re managing WordPress sites that have nothing to do with each other
Your sites have completely different branding, hosting needs, or security policies
You need complete isolation (Multisite assumes a level of trust between subsites)
Your sites have different plugin requirements that would bloat the network

The rule of thumb: Multisite shines when you have strategic overlap but operational independence.

WordPress Multisite vs. Separate Installs with Jobber

Let’s compare apples to apples.

Separate WordPress Installs (Traditional)

Each site gets its own codebase, database, and Jobber OAuth connection.

Pros: Complete isolation, easier to scale horizontally, no shared resource bottlenecks.

Cons: Plugin updates mean touching N sites. You’re managing N WordPress admin panels. DNS and SSL certificates are scattered. Jobber API limits apply per site, but your infrastructure sprawls.

WordPress Multisite with Jobber

One WordPress network, multiple subsites. Each subsite has its own Jobber Integration Pro instance with its own OAuth token.

Pros: One codebase to update, centralized plugin management, single dashboard for admin operations, shared infrastructure costs, unified backup strategy.

Cons: More moving parts, requires deeper WordPress knowledge, API rate limits shared if you’re using the same Jobber account across subsites (we’ll address this).

The verdict: Multisite wins for coordinated operations. Separate installs win for true independence.

Setting Up WordPress Multisite: The Foundation

Here’s where it gets interesting. You’ll need to enable Multisite on your WordPress install. It’s a one-time setup—sounds scarier than it actually is—and it requires editing two files: wp-config.php and .htaccess.

// In wp-config.php, add this before "That's all, stop editing!":

define('WP_ALLOW_MULTISITE', true);

/* That's all, stop editing! */

Once you’ve added that, go to Tools → Network Setup in WordPress admin. WordPress will guide you through creating your network structure. You can choose:

Subdomains: Each site is chicago.example.com, denver.example.com
Subdirectories: Each site is example.com/chicago/, example.com/denver/

For service businesses, subdomains usually feel more professional. Your franchisees see denver-hvac.example.com, not example.com/denver/.

After Network Setup completes, you’ll need to update .htaccess:

# BEGIN WordPress Multisite
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*.php)$ wp/index.php [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress Multisite

That .htaccess file is crucial. It tells the server that all traffic should flow through a single WordPress entry point, and WordPress figures out which subsite should handle it.

Configuring Jobber Integration Pro Across Subsites

Now we’re getting into the interesting part. Jobber Integration Pro is built for single sites. Multisite does something clever with that—instead of forcing all subsites to share one connection, it gives each its own OAuth token. You get independence without fragmentation. Not bad, right?

The OAuth Flow Per Subsite

When you activate Jobber Integration Pro on a subsite, you’re essentially saying: “This site needs to authenticate with a specific Jobber account.” The plugin handles OAuth, but the token is stored in that subsite’s options.

In wp-options, each subsite maintains:

// Each subsite stores its own OAuth token
get_option('jobber_oauth_token');
get_option('jobber_oauth_expires');
get_option('jobber_api_key');

When you visit a subsite’s admin and go to Settings → Jobber Integration, you’ll see the OAuth login button. Click it, authenticate with Jobber, and you’re setting up that specific subsite’s connection.

Important: The OAuth token is encrypted using wp_hash(), which is salted with your site’s SECURE_AUTH_KEY. Because Multisite shares one wp-config.php, tokens from different subsites are secure but managed in the same database. This is fine—don’t worry that they’re in the same table. The encryption is per-site.

Setting Up N Subsites with N Jobber Accounts

Here’s the typical franchise scenario:

Denver location: Has its own Jobber account for booking jobs in the Denver area
Chicago location: Has its own Jobber account
Portland location: Same pattern

You’ve created three subsites: denver-hvac.example.com, chicago-hvac.example.com, portland-hvac.example.com.

Process:

Go to My Sites → Denver Site → Settings → Jobber Integration
Click “Connect to Jobber”
Log in with Denver’s Jobber credentials
Authorize the OAuth request
The token is stored for the Denver subsite only
Repeat for Chicago and Portland

Each subsite now has its own independent Jobber connection. Bookings submitted on denver-hvac.example.com go to Denver’s Jobber account. Chicago submissions go to Chicago’s account.

Shared Account Scenario (Single Jobber Account, Multiple Subsites)

Sometimes you don’t want separate Jobber accounts. Maybe you’re an agency with one master Jobber account, and you’re setting up subsites for presentation or testing.

In this case, you have a choice:

Option A: Authenticate the first subsite, then copy its OAuth token to other subsites via the WordPress database.

-- Get the token from the first subsite (blog_id = 1):
SELECT * FROM wp_options
WHERE option_name = 'jobber_oauth_token'
AND blog_id = 1;

-- This is mostly a last-resort approach; we don't recommend it because token refresh gets messy.

Option B (Better): Use a custom OAuth setup where a parent function authenticates once and passes the token to subsites. This requires modifying the plugin or using a custom helper.

Option C (Best): Create one Jobber account and authenticate subsites individually against it. Jobber’s OAuth allows multiple apps (subsites) to auth against the same account. You’ll see all the tokens in your Jobber account settings.

We recommend Option C because it keeps things clean and avoids database manipulation.

Network-Wide Plugin Activation vs. Per-Site Activation

Trust me on this one—this is a critical decision: Do you activate Jobber Integration Pro network-wide, or per-site?

Network-wide activation (wp-cli command plugins activate jobber-integration-pro --network):

The plugin is active on all subsites
Settings in wp-config.php apply everywhere
Easier for large deployments
Harder to have different configurations per site

Per-site activation:

Each subsite “sees” the plugin only if it’s activated there
Different subsites can have different settings
More granular control
Slightly more overhead

Our recommendation: Activate network-wide. Jobber Integration Pro is designed to be agnostic per-site anyway (since each subsite stores its own OAuth token). Network-wide activation means:

One codebase to update
Consistent plugin version across all sites
Each site still gets independent OAuth and settings

Use WP-CLI to activate it:

wp plugin activate jobber-integration-pro --network

Configuring Network-Wide Settings vs. Per-Site Overrides

Jobber Integration Pro stores settings in wp_options. In Multisite, these are per-site, but you can create network-level defaults and allow subsites to override.

Here’s a pattern you might use:

// In a custom helper function:
function get_jobber_setting($key, $default = null) {
    // First, check if this subsite has a custom value
    $site_value = get_option("jobber_{$key}");

    if ($site_value !== false) {
        return $site_value;
    }

    // Fall back to network option
    $network_value = get_site_option("jobber_network_{$key}");

    if ($network_value !== false) {
        return $network_value;
    }

    return $default;
}

// Usage:
$trust_proxy = get_jobber_setting('trust_proxy_headers', false);
$duplicate_handling = get_jobber_setting('duplicate_client_handling', 'create_new');

This way, you can set network defaults (e.g., “All sites should trust proxy headers”), but specific subsites can override if needed (e.g., “Chicago location uses a custom reverse proxy”).

In the Jobber Integration Pro admin page, add a checkbox: “Use network default for this setting?” If checked, the site inherits from network options. If unchecked, it uses its own value.

Handling Jobber API Rate Limits in Multisite

Seriously. Here’s a gotcha many people miss: Jobber API rate limits are shared at the account level, not per site.

Jobber’s rate limit is 10,000 points per second window, restoring 500 points per second. This limit applies to your Jobber account.

If you’re running two subsites against the same Jobber account:

Denver site makes 3,000 API calls
Chicago site makes 4,000 API calls
Combined, you’ve used 7,000 of your 10,000 points

You can still make 3,000 more calls before hitting the limit.

If you’re running subsites against separate Jobber accounts, each account gets its own 10,000-point limit. No conflict.

Best practices:

Monitor rate limit per account: Jobber Integration Pro includes an API Health dashboard. Check it regularly. Look for subsites that are making unexpectedly high API calls (could indicate a plugin conflict or a webhook loop).
Implement exponential backoff: When a site hits the rate limit, it should retry with increasing delay.

function make_jobber_api_call_with_backoff($endpoint, $data, $max_retries = 3) {
    for ($i = 0; $i < $max_retries; $i++) {
        $response = wp_remote_post(
            "https://api.getjobber.com/api/v2{$endpoint}",
            [
                'headers' => [
                    'Content-Type' => 'application/json',
                    'Authorization' => 'Bearer ' . get_option('jobber_oauth_token'),
                ],
                'body' => json_encode($data),
            ]
        );

        if (is_wp_error($response)) {
            $error_code = $response->get_error_code();

            // Rate limit error?
            if ($error_code === 429) {
                $backoff = pow(2, $i); // 1s, 2s, 4s
                sleep($backoff);
                continue;
            }

            return $response;
        }

        return $response;
    }

    return new WP_Error('max_retries', 'API call failed after retries');
}

Batch requests when possible: Instead of making 100 individual calls, see if Jobber’s API supports batch endpoints.

Use Case #1: Franchise Model with Location-Specific Sites

You own a commercial cleaning service with franchises in Denver, Boulder, and Fort Collins. Each franchisee has their own Jobber account (so they control their own clients and jobs), but they all use your brand and template.

Architecture:

example.com (main site)
├── denver-cleaning.example.com (subsite 1, Jobber Account A)
├── boulder-cleaning.example.com (subsite 2, Jobber Account B)
└── fort-collins-cleaning.example.com (subsite 3, Jobber Account C)

Why Multisite here?

One WordPress codebase means you update templates once
Plugin updates apply to all sites
SSL certificate covers all subsites
Shared contact/about pages can be replicated via network template

Per-site independence:

Each franchisee authenticates their Jobber account
Each site has its own service area pages
Each site has its own testimonials and case studies
Bookings go to the correct Jobber account

Setup steps:

Install WordPress Multisite
Create three subsites
Configure DNS for each subdomain
Install Jobber Integration Pro network-wide
On each subsite, go to Settings → Jobber Integration and authenticate
Each franchisee sees their own booking form, pulling data from their Jobber account

Webhook automation:

You can set up webhooks that trigger WordPress actions when a job is created or quoted:

// Register webhook action
add_action('jobber_webhook_job/create', function($data) {
    // When a job is created in Jobber, log it in WordPress
    $job_id = $data['job']['id'];
    $client_name = $data['job']['client']['name'];

    // Email notification to site admin
    wp_mail(
        get_option('admin_email'),
        "New Jobber Job: {$client_name}",
        "Job ID: {$job_id}nClient: {$client_name}"
    );
});

// Jobber sends a POST to:
// https://denver-cleaning.example.com/wp-json/jobber/v1/webhook
// WordPress routes this to the jobber_webhook_job/create action

Each subsite has its own webhook endpoint, so webhooks are routed correctly.

Use Case #2: Agency Managing Multiple Jobber Clients

You run a digital marketing agency. Your clients include plumbing companies, electricians, and HVAC contractors. Each client uses Jobber for their business, and you’re managing their WordPress websites.

Architecture:

agency-portfolio.com (main site)
├── smith-plumbing.example.com (subsite, their Jobber account)
├── jones-electric.example.com (subsite, their Jobber account)
└── acme-hvac.example.com (subsite, their Jobber account)

Why Multisite here?

You maintain one WordPress network instead of three separate installations
Updates roll out to all client sites at once
You manage backups, security, and plugins centrally
Each client gets their own branded site and independent Jobber integration

Per-site customization:

Each client can customize their site’s appearance
Each client’s Jobber account is independent (they control their clients and pricing)
You can still enforce network-wide security policies (MFA, password requirements, etc.)

Setup steps:

Create the Multisite network
Create subsites for each client
Authenticate each client’s Jobber account on their subsite
Set up SSL (wildcard cert covers all subsites)
Use a management dashboard to monitor all subsites from the main site

Client portal example:

Build a custom admin page on the main site that displays stats across all subsites:

// On the main site's admin dashboard
function display_client_network_stats() {
    $sites = get_sites(['network_id' => get_current_network_id()]);

    echo '<table>';
    echo '<tr><th>Client</th><th>Domain</th><th>Jobber Status</th><th>Jobs This Month</th></tr>';

    foreach ($sites as $site) {
        switch_to_blog($site->blog_id);

        $domain = get_site_url();
        $jobber_token = get_option('jobber_oauth_token');
        $connected = !empty($jobber_token) ? 'Connected' : 'Not Connected';

        // Could call Jobber API to fetch job count
        $jobs_count = 0; // placeholder

        echo "<tr>";
        echo "<td>{$site->blogname}</td>";
        echo "<td>{$domain}</td>";
        echo "<td>{$connected}</td>";
        echo "<td>{$jobs_count}</td>";
        echo "</tr>";

        restore_current_blog();
    }

    echo '</table>';
}

This gives you a high-level view of all your clients without jumping between sites.

DNS and Domain Mapping for Service Area Sites

If you’re using subdomains, DNS setup is straightforward:

denver.example.com          CNAME example.com
chicago.example.com         CNAME example.com
portland.example.com        CNAME example.com

Your DNS provider sees all three as aliases pointing to the same hosting server. WordPress Multisite then looks at the subdomain and routes to the correct site.

If you want your franchisees to use their own domains:

This requires the WordPress MU Domain Mapping plugin. A franchisee owns denver-hvac-services.com and wants to use it instead of denver.example.com.

Install the Domain Mapping plugin
In Network Admin → Settings → Domain Mapping, add the custom domain
Update the franchisee’s DNS:

denver-hvac-services.com    A  [your-ip-address]
www.denver-hvac-services.com A  [your-ip-address]

The Domain Mapping plugin intercepts the request, looks up the custom domain, and serves the correct subsite.

SSL certificates:

With subdomains, use a wildcard certificate: *.example.com

With custom domains, you’ll need either:

A multi-domain (SAN) certificate listing all custom domains
Let’s Encrypt with wildcard for your domain + custom certs for franchisee domains (automated via ACME)

Performance Considerations: Multisite + Jobber API

Multisite adds layers of logic (site detection, context switching), and Jobber API adds network I/O. Here’s how to keep things snappy.

1. Database Query Optimization

Multisite queries are more complex because they filter by blog_id. Use proper indexes:

-- Ensure index on blog_id + option_name
ALTER TABLE wp_options ADD INDEX blog_option (blog_id, option_name);

When you call get_option() on a subsite, WordPress queries wp_options WHERE blog_id = X AND option_name = 'key'. The index speeds this up.

2. Caching Jobber API Responses

Don’t call the Jobber API on every page load. Cache the response:

function get_jobber_services_cached($cache_time = 3600) {
    $cache_key = 'jobber_services_' . get_current_blog_id();
    $cached = wp_cache_get($cache_key);

    if ($cached !== false) {
        return $cached;
    }

    // API call
    $response = wp_remote_get('https://api.getjobber.com/api/v2/services', [
        'headers' => [
            'Authorization' => 'Bearer ' . get_option('jobber_oauth_token'),
        ],
    ]);

    $data = json_decode(wp_remote_retrieve_body($response), true);

    // Cache for 1 hour
    wp_cache_set($cache_key, $data, '', $cache_time);

    return $data;
}

3. Lazy Load Multisite Subsites

If you have 50 subsites, don’t load all of them when a network admin page loads. Use pagination:

$sites = get_sites([
    'network_id' => get_current_network_id(),
    'number' => 20,
    'offset' => 0,
    'orderby' => 'id',
    'order' => 'ASC',
]);

Fetch 20 at a time, page through them, instead of loading all 50 into memory.

4. Async Jobber Webhook Processing

When Jobber sends a webhook, don’t process it synchronously. Queue it for async processing:

function handle_jobber_webhook($payload) {
    // Queue the job for async processing
    as_enqueue_async_action('process_jobber_webhook', [$payload]);

    // Return 200 OK to Jobber immediately
    return rest_ensure_response(['status' => 'queued']);
}

add_action('process_jobber_webhook', function($payload) {
    // Heavy lifting: update client data, send emails, etc.
    // This runs outside the HTTP request cycle
});

This keeps your webhook endpoint fast and prevents timeouts.

Monitoring and Centralized Analytics

One reason to use Multisite is unified monitoring. Set up a custom dashboard on the main site:

function network_admin_dashboard_widget() {
    $sites = get_sites(['network_id' => get_current_network_id()]);
    $total_posts = 0;
    $total_api_calls = 0;

    foreach ($sites as $site) {
        switch_to_blog($site->blog_id);

        $total_posts += wp_count_posts()->publish;
        $total_api_calls += get_option('jobber_api_call_count', 0);

        restore_current_blog();
    }

    echo "<div class='dashboard-widget'>";
    echo "<p>Network Total Posts: {$total_posts}</p>";
    echo "<p>API Calls This Month: {$total_api_calls}</p>";
    echo "</div>";
}

add_action('wp_dashboard_setup', function() {
    wp_add_dashboard_widget(
        'network_jobber_stats',
        'Network Jobber Stats',
        'network_admin_dashboard_widget'
    );
});

This aggregates data across all subsites in one place.

Common Pitfalls and How to Avoid Them

Pitfall #1: Forgetting to activate Jobber Integration Pro network-wide

If you activate it on a single site, other subsites won’t see it. Use WP-CLI:

wp plugin activate jobber-integration-pro --network
wp plugin list --network

Pitfall #2: Sharing OAuth tokens between subsites

Don’t manually copy tokens. Let each site authenticate independently. If you must share a Jobber account, use Option C from earlier: authenticate subsites individually against the same account.

Pitfall #3: Not monitoring API rate limits

Set up monitoring for the Jobber API Health dashboard. Alert yourself if any subsite is consistently hitting high percentages of the rate limit.

Pitfall #4: Assuming multisite backups are simple

Multisite databases are bigger and backups take longer. Use wp-cli or a plugin like UpdraftPlus that understands Multisite structure.

wp db export network-backup-$(date +%Y%m%d).sql

Pitfall #5: Mixing subdomains and custom domains without proper mapping

Domain mapping is optional but requires the plugin and careful DNS setup. Don’t mix approaches without understanding the routing.

Wrapping Up

You’ve now got the playbook for WordPress Multisite with Jobber. Is it the right move for your operation? That depends on your setup. But if you’re already juggling multiple sites, the unified management, centralized updates, and independent per-site Jobber connections give you something most multi-site operations dream about: control without chaos.

One update rolls out to all sites. One backup strategy secures everything. One dashboard shows you the entire network’s health. Yeah, there’s setup complexity, but the ROI is significant once you’re scaling beyond two or three sites.

Related Resources:

Ready to connect Jobber to your WordPress site? Native forms, real-time API, no Zapier needed. Get Jobber Integration Pro – $99/year

Jobber WordPress Multisite: Managing Multiple Service Business Websites from One Dashboard