JobNimbus integrations make roofing marketing attributable when every lead source, meaning web forms, tracked calls, Local Services Ads, Google Ads lead forms and any front-end CRM, creates a contact and a job in JobNimbus with the Lead Source field set at the moment of creation, deduped by phone and email, with the JobNimbus id written back to the tool that sent it, and a daily reconcile that catches anything missing. Do that and the sold report inside JobNimbus becomes a marketing report. This piece covers the ways in, the fields that matter, the wiring for each lead source, the dedupe and retry logic, and the same pattern in AccuLynx.
JobNimbus is a roofing CRM and job management platform where contacts and jobs sit on boards with statuses, and the Lead Source field on each record is the only link between a sold roof and the marketing that produced it. We have built this wiring for roofing companies; this is the method that held up.
Why attribution breaks inside JobNimbus.
The typical roofing company has five or six ways a homeowner can reach it: a website form, a phone number, a Local Services Ads listing, ad lead forms, and referrals that arrive by text to the owner. Each lands in a different inbox. Somebody keys the contact into JobNimbus a day later and picks whatever Lead Source seems close. By quarter end the report shows mostly Website, Referral and Other, and the owner still cannot tell whether the ad budget produces roofs.
The failure is structural, not a training problem. JobNimbus can only report what it was given at creation, so the record has to be created by the system that knows where the lead came from, not by a person guessing later.
“If Lead Source is blank when the record is created, no report you run later will ever tell you which ad paid for that roof.”
The three ways into JobNimbus.
JobNimbus exposes an API with a key issued per account, and it has native connectors on both Zapier and Make. The choice between them is about who will maintain the integration, not capability.
- Direct API with the account key: the most control and the only option when you need to queue, retry and reconcile on your own terms. It requires someone who can maintain a small service.
- Zapier: fastest to stand up and easiest for an office manager to read. Multi-step zaps with search-before-create steps get expensive and hard to debug at volume.
- Make: cheaper per operation at scale and better at branching, so one scenario can search, create a contact, create a job and write an id back.
Whichever door you choose, generate the API key from a dedicated integration user rather than the owner's login, so every automated record is stamped with a name like Integrations and a human can tell at a glance what the system created.
The fields that have to be set on creation.
Four fields decide whether the integration is useful. Everything else can be cleaned up later; these four cannot.
- Lead Source on the contact, from a fixed list you control (Website Form, Website Call, LSA, Google Ads Lead Form, Facebook Lead Form, Referral, Door Knock, Repeat Customer).
- Board and status for the contact, normally the Contacts board with a status like New Lead, so it appears where the office already looks.
- A job on the New Opportunity board created alongside the contact, carrying the same source, because the sold report in JobNimbus is a job report, not a contact report.
- An external id on both records holding the id from the sending system (form submission id, CallRail call id, HubSpot contact id), so the reconcile can match without relying on names.
The job-per-lead rule surprises people. Roofers often create the job only after an inspection. That habit breaks attribution, because the source lives on the contact and the revenue lives on the job. Create the job at intake with the source copied onto it, and let the board show the funnel from New Opportunity to Inspected to Estimate Sent to Sold.
How to wire each lead source.
Dedupe before you create.
A homeowner who fills the form, then calls, then clicks the LSA listing is one lead, not three. Every creation path must search JobNimbus first, by phone normalized to digits and then by email lowercased, and only create when both come back empty. When a match exists, append a note recording the second touch and its source; the first touch keeps the attribution.
The other half of dedupe is writing the JobNimbus id back to the system that sent the lead. If HubSpot or the form tool stores the JobNimbus contact id, a retry after a timeout cannot create a second record, and a person can jump from the HubSpot contact straight to the job. We treat a failed write-back as a failure of the whole creation step.
Queue, retry and the CloudFront 403.
JobNimbus sits behind CloudFront, and bursts of automated requests can come back as a 403 that looks like an authorization failure but is really rate limiting at the edge. One lead means five calls in a row, and a busy morning with twenty leads will hit it. A naive zap simply fails and the lead is lost silently.
The fix is a queue. Every inbound lead goes into a queue, and a worker drains it one at a time with a short delay between calls. On a 403 or 5xx the worker retries with backoff, doubling the wait up to a cap, and only marks the lead failed after several attempts, at which point a person gets an alert. In Make this is a data store plus a scheduled scenario; in Zapier a delay step and a paths step; in a custom service a few dozen lines. The lead must never be dropped because the API said no once.
The daily reconcile.
Integrations rot. A form field gets renamed, a CallRail number is reassigned, a Zapier task limit is hit, a board is renamed by a well-meaning office manager. None of these throw an error you will see. The only defense is a daily job that pulls yesterday's leads from each source and yesterday's contacts from JobNimbus, matches them by external id, phone and email, and reports three lists: in the source but missing in JobNimbus, in JobNimbus with a blank or Other source, and in JobNimbus but missing from every source, which usually means untagged hand entry.
That report goes to one named person by email every morning. Most days it is empty. On the day it is not, it catches the break within twenty-four hours instead of at quarter end. The reconcile is also what makes the sold report trustworthy enough to feed back into Google Ads as offline conversions, the subject of our conversion tracking audit checklist.
| Lead source | Path into JobNimbus | What sets Lead Source | What to watch |
|---|---|---|---|
| Website form | Webhook to Make, Zapier or a custom handler, then API | The handler, from the form's hidden source field | Renamed form fields, spam submissions, missing write-back |
| Tracked call (CallRail) | CallRail trigger in Zapier or Make, then API | The tracking number's source name | Duration threshold, missed calls, reassigned numbers |
| Local Services Ads | Email parser or LSA lead connector, then API | Fixed value LSA | Parser breaks when the email format changes, disputes not filed |
| Google Ads lead form | Webhook from Google Ads, then API | Fixed value plus campaign name in a custom field | Webhook key rotation, test leads from the ad platform |
| HubSpot or GoHighLevel | Native connector or API from the front-end CRM | Copied from the CRM's original source property | Connector syncs contacts but not jobs, source overwritten on update |
| Referral or walk-in | Hand entry in JobNimbus | Required field in the contact template | Users picking Website when they mean Referral |
The same pattern in AccuLynx.
Everything above transfers to AccuLynx with different nouns. AccuLynx has leads and jobs with a lead source field, an API on some plans, and connectors on the automation platforms. The rules are identical: set the source on creation from the system that knows it, create the job at intake, dedupe by phone and email, write the AccuLynx id back, queue and retry, and reconcile daily. If you are still choosing between the two, ask whether the integration can set the source and whether sold status can get back out; we work through that choice with roofing companies regularly.
What usually goes wrong.
- Contacts are created without jobs, so the sold report has no source to show. Fix: create the job on the New Opportunity board at intake, every time.
- Lead Source is free text in the automation, so Website, website and Web Form become three sources. Fix: a fixed list, enforced in the handler and in the JobNimbus template.
- A 403 from CloudFront during a busy morning silently drops leads because the zap has no retry. Fix: queue with backoff and a failed-lead alert.
- Nobody owns the reconcile, so the integration breaks in March and is discovered in June. Fix: a daily email to a named person, empty on good days.
- Sold status never leaves JobNimbus, so Google Ads keeps optimizing toward form fills instead of roofs. Fix: export sold jobs with their source on a schedule and upload them as offline conversions.
None of this is exotic. It is a handful of decisions made once and enforced by software instead of by a person remembering. When we build lead systems for roofers, the JobNimbus wiring is the first week and the callback automation in front of it is the second, because the fastest callback still needs a clean record to land on. Our piece on speed to lead covers that second week.
Does JobNimbus have an API for integrations?
Yes. JobNimbus issues an API key per account, and the API can search, create and update contacts, jobs, notes and tasks. It also has native connectors on Zapier and Make. For a roofing company, the API is the right choice when you need queuing, retries and a daily reconcile; Zapier or Make is fine for simple form-to-contact flows.
How do I get CallRail calls into JobNimbus?
Use the CallRail trigger in Zapier or Make on a completed call. Search JobNimbus by the caller's phone number first, then create a contact with Lead Source set from the tracking number's source and a job on the New Opportunity board. Put the recording link in the first note, and create a Missed Call record for unanswered calls.
Why does my JobNimbus automation get a 403 error?
JobNimbus sits behind CloudFront, and bursts of automated requests can be rejected with a 403 at the edge even when your API key is valid. Space the calls out, put inbound leads in a queue, and retry with increasing delays on a 403 or 5xx. Alert a person only after several failed attempts so no lead is dropped silently.
Can I get sold jobs out of JobNimbus into Google Ads?
Yes, with a scheduled export. Pull jobs that reached Sold in the last period along with their Lead Source, external id and click identifiers stored at intake, then upload them to Google Ads as offline conversions. This lets the ad platform optimize toward roofs instead of form fills, which only works if the click data was captured at creation.