What Jobber sends — and what ReviewNudger requires
The integration starts from a specific provider event, then resolves only the payment and customer facts listed here.
Accepted provider event
INVOICE_UPDATE → fetched invoice status is paid
ReviewNudger receives Jobber's INVOICE_UPDATE webhook, fetches the current invoice, and proceeds only when that invoice's status is paid. Other invoice updates are ignored.
Paid invoice with a total
The fetched Jobber invoice must have paid status and a usable invoice total.
An attached client with contact data
The invoice must be attached to a Jobber client with email or phone. Primary contact values are preferred, then the first usable value.
A usable sending route
The location must have automation enabled, and the client must pass cooldown, do-not-contact, and channel opt-out checks.
See the connection and its latest event
The connected-apps view shows whether Jobber is connected, whether ReviewNudger has received an event, and whether that event was processed or needs attention.

Illustrative product walkthrough using fictional Summit Plumbing data — not a customer case study.
From paid event to request, every step stays visible
The request journey records the trigger, initial delivery, follow-ups, stops, and outcomes in one timeline.
- 1Connect your Jobber account to ReviewNudger with a secure OAuth authorization. Your jobs, clients, and invoices stay in Jobber; ReviewNudger only listens for invoice updates.
- 2When an invoice is marked paid in Jobber, ReviewNudger receives the event, pulls the client's contact details, and applies your sending rules. It can then send one neutral Google review request by SMS or email at the time you set.
- 3Every send is tracked with delivery status, opt-outs, and review click-through, so your review pipeline is as visible as your job pipeline.

Illustrative product walkthrough using fictional Summit Plumbing data — not a customer case study.
What happens when the clean path is not available
Skipped and failed events are recorded with a reason. Nothing silently guesses a customer or sends around an opt-out.
Retries collapse onto one journey
Provider retries and repeated updates reuse the same provider payment identity. They cannot create a second ReviewNudger review-request journey.
Missing facts fail visibly
ReviewNudger requires the provider's amount and customer contact facts. If either is missing, the incoming event records the failure and no customer is guessed.
Sending rules can suppress the request
Disabled automation, an active cooldown, do-not-contact state, or an opt-out on the usable channel suppresses the request with a visible reason.
Refunds do not create or rewind journeys
Refund and reversal events do not create another request. They also do not automatically cancel a journey that already exists; an operator can cancel a queued request or stop later follow-ups.
Invoice updates are re-fetched
The webhook is a signal, not the final status claim. ReviewNudger fetches the invoice from Jobber and uses its current status and client relationship.
No attached client means no guess
A paid invoice without an attached client, amount, or usable client contact is shown as a failed incoming event and does not create a request.
Email can carry the first request while SMS waits
A newly registered SMS number must be approved before it can send customer messages. ReviewNudger never sends from a number that is still pending.
Use email when it is allowed and usable
If the customer has email, the location has email enabled, and the required business address is configured, email carries the initial request while SMS is under carrier review.
Otherwise, keep the event recoverable
If no usable email route exists, the event is visibly suppressed as sms_not_ready. After SMS approval, an operator can recover it from recent events instead of asking the provider to send it again.
Connect Jobber and prove the trigger end to end
Have these provider and ReviewNudger details ready before you connect.
Before you start
- A Jobber account and permission to approve the secure OAuth connection.
- Invoices attached to clients with email or phone, with primary contact values set when possible.
- A completed ReviewNudger location with its Google review destination and sending channels configured.
- 1Start a ReviewNudger trial and finish the short signup.
- 2Choose Jobber as your trigger and approve the OAuth connection.
- 3Mark a real invoice paid in Jobber to confirm the trigger end to end.
- 4Done. Every client now gets one automatic review request after paying.
Jobber integration questions
Do I need a Zapier account to connect Jobber?
No. The Jobber integration is native: you connect it directly inside ReviewNudger, with no middleware account, no per-task automation fees, and no field mapping to maintain.
What exactly triggers a review request?
Each time an invoice is marked paid in Jobber, ReviewNudger records the event and evaluates it against your per-location send delay, cooldown, contact, and channel rules. One matching event can create one review-request journey by SMS or email.
Can a retry or duplicate webhook double-text a customer?
No. Every incoming event is deduplicated before any message is sent, and each event can create at most one review request. Provider retries and replays collapse onto the same request instead of sending twice.
What about customers who opt out?
SMS recipients can reply STOP at any time and email recipients can unsubscribe. Opt-outs are recorded per customer and honored across every future Jobber-triggered event.
Does every Jobber invoice update trigger a request?
No. ReviewNudger fetches the invoice after INVOICE_UPDATE and proceeds only when its current status is paid. The invoice also needs a total and an attached client with a usable email address or phone number.
Questions before you start? Email support@reviewnudger.com and a human will answer.
