Jobber Integration for Rain Automation: Connect Field Service Work to Any Workflow
Rain Automation connects Jobber's GraphQL API to everything around it, so leads, quotes, visits and invoices move without anyone retyping them. The integration runs both directions: Jobber webhooks trigger Rain workflows, and Rain writes back clients, properties, requests, quotes, jobs, visits and invoices. One limit is worth stating up front, because it shapes what can be built: Jobber's API has no payment creation mutation, so Rain can read payments and react to them but cannot record one.
How to connect Jobber
Jobber uses OAuth 2.0 and a versioned GraphQL API at https://api.getjobber.com/api/graphql. There is no one click marketplace install, so the connection is a short, ordered setup that Rain performs with you.
Step 1. Create the app at developer.getjobber.com
Sign in with the Jobber account you want to automate and create a developer app. Creating the app and approving it later does not consume a Jobber user seat, so connecting Rain does not change your Jobber bill.
Step 2. Choose the scopes you actually need
Request read and write on the objects the workflows will touch: clients, properties, requests, quotes, jobs, visits, invoices, and products and services. Payments are read only by design, so ask for the payments read scope and nothing more. Scopes are easier to widen later than to explain to a security reviewer now.
Step 3. Set the redirect URI to Rain
Point the app's redirect URI at the Rain callback we give you. This is the address Jobber sends the one time authorization code to.
Step 4. Approve the connection as the Jobber account owner
Open the authorize URL, confirm you are on the right Jobber account, and click Allow. Rain exchanges the code for an access token (roughly one hour of life) and a long lived refresh token.
Step 5. Give exactly one service ownership of the refresh token
This is the step that decides whether the integration survives its first month. Jobber rotates the refresh token on every refresh and invalidates the entire token family if an old one is ever replayed. Two services refreshing at once will brick the connection. Rain stores the rotating token in a single database row, serialises every refresh behind a Postgres advisory lock, and exposes a broker endpoint that hands out short lived access tokens. Every other workflow, script and n8n node asks the broker instead of refreshing on its own, and the refresh token never lands in an environment file where a redeploy could reseed a stale copy.
Step 6. Pin the GraphQL version and watch it
Every request must send an X-JOBBER-GRAPHQL-VERSION header. Pin a known good version rather than tracking latest, then run a daily canary query so a schema change surfaces as an alert rather than as a workflow that quietly stopped creating clients.
Step 7. Subscribe to the webhook topics that drive your workflows
Register endpoints with webhookEndpointCreate. The useful topics include CLIENT_CREATE and CLIENT_UPDATE, REQUEST_*, QUOTE_*, JOB_CREATE, JOB_UPDATE and JOB_CLOSED, VISIT_COMPLETE, INVOICE_CREATE, INVOICE_UPDATE, PAYMENT_CREATE, PAYOUT_*, PROPERTY_*, PRODUCT_OR_SERVICE_*, and ON_MY_WAY_TRACKING_LINK_REQUEST. Webhooks remove polling entirely and keep you well inside the throttle.
Step 8. Build the first workflow against a test client
Create one throwaway client and run the full path end to end before pointing real leads at it. Jobber's mutations return a userErrors array alongside the payload, so a workflow that only checks for an HTTP 200 will happily report success while writing nothing. Rain treats a non empty userErrors as a hard failure and alerts on it.
What stays a click inside Jobber
Being accurate about the edges is faster than discovering them mid build:
- Payments cannot be created. No payment creation mutation exists anywhere in the API. Payments are readable and they fire webhooks, but recording one is a click in Jobber. Offline methods including cash, check, bank transfer, Cash App, PayPal, Venmo, Zelle and e-transfer are first class when a human records them.
- Request forms are invisible to the API. Request records are writable, but the form questions are not readable or writable in either direction. Form changes are screenshot verified UI work.
- Quote and invoice settings are not writable. There is no settings mutation for payment terms, default messages or request forms.
- Team permissions and pay are UI only. The user mutation accepts a name and nothing else, and Jobber has no commission or percentage pay field at all.
- Jobber Payments is an underwriting step. It is owner only, has no API, and while it is off the account cannot take a card at any point in the flow.
Related reading
- Google Local Services Ads lead response, the lead source feeding most of these workflows
- AI agents for service businesses
- Automation tools for service businesses: what actually saves time
- Automate Google review requests
- Customer lifecycle automation guide
- Multi stop route optimization, how it works and the Rain route planner
Example workflows
Google Local Services Ads lead to Jobber client and request
A lead arrives through Google Local Services Ads. Rain reads the message thread, qualifies it, matches or creates the client with clientCreate, attaches the service address as a property, and files a request with the full conversation as a note so the office sees what the customer actually asked for. Runs today for a residential cleaning company. More on the lead side at /google-local-services-ads.
Use case: Speed to lead
Website form to deduplicated Jobber request
A web form submission is matched against existing clients by email, phone and address before anything is written, so a repeat customer gets a new request on their existing record instead of a second client card. New names get clientCreate plus propertyCreate plus requestCreate in one transaction, with the raw submission preserved as a request note.
Use case: Clean CRM data
Qualified lead to draft quote awaiting approval
Rain reads your live price book from Jobber's products and services, prices the job from the details the customer gave, and creates the quote with quoteCreate in awaiting response state with its client hub link ready. Jobber has no mutation that sends a quote, so the send stays a deliberate click. That is the right place for a human gate anyway.
Use case: Faster quoting without losing control
Price book drift detector
The workflow nobody thinks to build until it bites them. Rain reads products and services on a schedule, caches it with a canonical signature, and compares every run. When someone edits a rate in Jobber, the quoting workflow picks up the new number on its next refresh and the change is logged and alerted rather than discovered weeks later in a quote that was priced off a stale cache.
Use case: Pricing integrity
Visit complete to review request
The VISIT_COMPLETE webhook fires the moment a crew closes out. Rain waits a set interval, checks the visit was not rescheduled or cancelled, and sends the review request by email or text with a direct link. Suppression rules keep the same customer from being asked twice in a season. See our guide on automating review requests.
Use case: Reputation on autopilot
Unpaid invoice watcher that respects the payments limit
Rain reacts to INVOICE_CREATE and PAYMENT_CREATE webhooks to track which invoices are actually settled, then escalates the aging ones to the owner with the client, the amount owed and the days outstanding. Because the API cannot create a payment, this workflow never tries. It hands a human a short, ordered list to work instead of a full receivables report.
Use case: Receivables follow up
Tomorrow's visits to an optimized crew route
Each evening Rain pulls the next day's scheduled visits with their property addresses, orders them into a route that respects time windows, and sends each cleaner their sequence before they start. Recurring jobs are created with an RRULE recurrence so the visit series exists in Jobber first and the route is always built from the real schedule.
Use case: Drive time reduction
Pricing
The Jobber API costs nothing extra. It ships with your Jobber account and a developer app adds no seat, so there is no per call or per connection fee from Jobber for the integration itself.
Rate limits are the real capacity question. Jobber uses a points bucket that restores continuously, and simple queries cost about one point. Event driven workflows built on webhooks sit far below the ceiling. Polling loops are what burn the budget, which is the main reason Rain builds these on webhooks.
Plan tier gates features, not access. Whether a feature exists on your account (online booking, client hub, automations, QuickBooks sync, Jobber Payments) depends on your Jobber plan and on account level feature flags. Rain reads those flags before scoping anything, because a workflow that depends on a disabled feature is a workflow that will never run.
Rain's side is an engagement, not a per connection charge. Jobber work is scoped as part of a build or an ongoing managed automation engagement. See pricing for how engagements are structured, or get in touch with the workflows you have in mind.