JobNimbus

Connect AI agents to JobNimbus, the CRM and job management platform for roofing and contracting. Agents create contacts and jobs, build estimates from the price list, raise invoices, log activities and tasks, and upload photos from the site.

27 actions API key available

JobNimbus website ↗ Platform Documentation ↗

An inbound lead arrives from a web form, an ad platform, or an SMS

The name, address, phone, and claim detail are parsed out of the message

List Contacts runs a filter on the phone or email to see whether this homeowner is already known

Create Contact writes the record with the workflow, status, and lead source names the account actually has

Create Activity logs the original message text so the timeline carries the evidence, not a summary

The sales rep is told a new lead landed and which existing record it was checked against

A person confirms the job status before Update Job advances work into a production stage

What This Integration Enables

JobNimbus is built for contractors who sell and deliver the same job, which is why its object model does not stop at the deal. A roofing business does not hand a signed contract to a separate delivery system, it moves the same job through a workflow that ends with a crew on a roof, an invoice, and a payment. This connector covers that whole arc: contacts and jobs with create, update, get, list, and delete; tasks and activities for the follow-up and the timeline; estimates, invoices, products, work orders, and payments for the money; and file upload for the photos and reports that make a claim defensible. The point of automating here is not tidier data entry. It is that the record a crew chief opens on a roof is accurate because a flow wrote it, not because someone remembered to.

The behaviour worth knowing before building is mostly about how JobNimbus expects to be addressed. Record Type and Status are sent by name and must match a workflow and a status already configured in the account, so the dictionaries behind those pickers read live from /account/settings and a name that does not exist is rejected outright. Record IDs are opaque jnid strings such as lz8y1afzet1, and the recid and number fields shown in the JobNimbus interface are not accepted where an ID is required. Timestamps are Unix seconds rather than milliseconds or ISO 8601, and a task with no end time carries date_end: 0. List Contacts, List Jobs, List Tasks, List Activities, and List Files take a JSON filter in the JobNimbus Elasticsearch style, so a change poll is {"must":[{"range":{"date_updated":{"gte":"now-1d"}}}]} and everything attached to one record is {"must":[{"term":{"related.id":"abc12345"}}]}, while the v2 list endpoints for estimates, invoices, products, work orders, and payments accept only Size and From and have to be narrowed in the flow. Records live under one host and file uploads go to a separate one using the same Bearer key. Delete Contact and Delete Job are soft deletes that send is_active: false, which is how JobNimbus removes these records through the API, so the record stays in account history and stops being returned as active. There are no triggers: the documented API publishes no endpoint for creating or deleting a webhook subscription, so nothing here can register a realtime listener. Change detection is a scheduled flow with a date_updated filter on the list actions.

Without FlowRunner

Leads sit in a mailbox The message arrives, and the record gets created whenever someone next opens the app

The timeline has gaps Calls and inspection notes are remembered rather than logged, so the job history is partial

Photos live on a phone Inspection images and measurement reports reach the job days after the inspection, or not at all

With FlowRunner

Leads become records at arrival The contact exists with its workflow, status, and lead source set the moment the lead lands

Every touch is on the timeline Calls, emails, and notes are written as activities against the contact or job as they happen

Documents attach themselves Reports and photos are pushed to the right job by the flow that produced them

Use Case Scenarios

An inbound lead that arrives complete instead of arriving as a name

A homeowner texts the office number and the message reaches the flow through Twilio. The agent parses the address, the phone, and whatever the homeowner said about the problem, then calls List Contacts with a term filter on the phone number to see whether this is a returning customer or a new one. For a new one it calls Create Contact with the workflow, status, and lead source resolved from the account's own settings, so the record lands in the right place in the sales board rather than in a default bucket someone has to move it out of later. It then calls Create Activity with the verbatim message text and an activity type, which puts the homeowner's own words on the timeline where the rep will read them. Custom fields pass through verbatim keyed by the JobNimbus field label or system name, so a claim number captured in the form arrives on the record rather than in a note.

Inspection reports and photos that reach the job the same day

An inspection produces measurements and photos, and a document generator such as PDFMonkey renders the signed report. The agent takes the returned document URL and calls Upload File against the job, which runs the documented three step upload: JobNimbus issues a presigned URL and reserves the file record, the bytes are fetched from the supplied URL and sent to that presigned URL, then the upload is completed and a thumbnail is requested. The presigned URL is valid for fifteen minutes and the endpoint is intended for files under 100 MB, so the flow keeps the fetch and the send inside one run. The attachment category is set explicitly rather than defaulted, because Photo and Document sort differently in the app and a claim reviewer looks in one of them. List Files with a related.id filter then confirms what the job actually holds, which is the check that catches a report uploaded against last month's job.

A collections report that reads the money side without touching it

On a schedule, the agent calls List Invoices and List Payments, both of which accept only Size and From, so it pages through and joins them in the flow rather than in the query. It reads List Work Orders for work committed but not yet billed, noting that the count returned there reflects every work order in the account rather than the number of records on the current page. The joined set becomes a weekly outstanding balance sheet in Google Sheets with each row linked back to its job. Nothing is written to JobNimbus in this flow. That is deliberate: a read-only run can be scheduled daily without anyone approving it, and the writes it suggests go through the gate below.

Human-in-Loop Highlight

The delete on this connector is soft. Delete Contact and Delete Job send is_active: false, the record stays in account history, and a person can bring it back. So the gate does not belong on the delete, and putting it there would be theatre. It belongs on Update Job, specifically on the status change, because in JobNimbus a status is not a label on a record, it is the instruction that starts the physical work. Record Type and Status are sent by name and must match a workflow configured in the account, and JobNimbus rejects a name that does not exist. What it does not do, and cannot do, is reject a name that exists but is wrong for this job. Move a job into a production status and the crew scheduling, the material order, and the customer's expectation all move with it, and none of those unwind by setting the status back. A truck gets loaded. Shingles get delivered to an address. So the agent assembles the case and stops. It calls List Jobs with a filter for jobs whose upstream signal says the deposit cleared or the estimate was signed, calls Get Job on each to read the current status and owner, and posts to the production manager: "Eleven jobs look ready to advance from Signed to Production. Nine have a signed estimate and a recorded payment. Two have a signed estimate with no payment against them, listed here with the homeowner and the address. Advancing a job schedules the crew and releases the material order, and setting the status back does not recall either. Advance all eleven, advance the nine, or hold?" The manager answers once, and only then does the agent call Update Job for the approved set and Create Task to assign the crew lead. This is the human-in-the-loop moment that matters on a contracting platform, because the expensive mistake here is not a bad record, it is a truck at the wrong house.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

27 actions

Contacts

Create Contact Creates a contact with a workflow, status, and lead source sent by name, matching values already configured in the account. Used as the entry point for every inbound lead.
Update Contact Updates a contact, including its status within the contact workflow. Used to reflect qualification decided in another system.
Delete Contact Sends `is_active: false`, which is how JobNimbus removes a contact through the API. The record stays in account history and stops being returned as active.
Get Contact Retrieves a single contact by its `jnid`. Used to confirm current state and ownership before a write.
List Contacts Returns contacts filtered with the JobNimbus Elasticsearch style JSON filter, with Size, From, sort, and a fields projection. This is the dedup check and the change poll.

Jobs

Create Job Creates a job with its record type and status sent by name. Used when a sold lead becomes work to deliver.
Update Job Updates a job, including the status that advances it through the account's workflow. Because a status change drives crew scheduling and material ordering downstream, this action runs on an approved set.
Delete Job Sends `is_active: false` to remove the job through the API. The record remains in account history.
Get Job Retrieves a single job. Used to read the current status and owner before proposing a move.
List Jobs Returns jobs with the same filter, paging, and sort options as List Contacts. Used for pipeline sweeps and for change detection with a `date_updated` range.

Tasks

Create Task Creates a task with a task type name taken from the account settings, assigned to a user with a due date. Used to make a follow-up concrete inside the run that identified it.
Update Task Updates a task, including assignment, dates, and completion. Used to close out work a flow finished.
Get Task Retrieves a single task. Note that a task with no end time carries `date_end: 0` rather than a null.
List Tasks Returns tasks with the JSON filter, so overdue and unassigned work can be found on a schedule.

Activities

Create Activity Writes a note, call, or inspection entry onto a record's timeline. It takes the note text, an activity type name, and the Primary Record `jnid` of the contact or job it belongs to.
List Activities Returns activities with the JSON filter. The collection comes back under an `activity` key rather than the usual `results`, so a flow reading it needs to expect that envelope.

Estimates

Create Estimate Creates an estimate with one line item per product or service, where line item prices may be negative to record a discount. Estimate status is a numeric ID configured per account.
List Estimates Returns estimates with Size and From only, no filter or sort. This is also how to discover the numeric status IDs the account uses.

Invoices

Create Invoice Creates an invoice using the same line item shape as estimates and work orders: name, description, quantity, price, cost, unit of measure, item type, and an optional price list product ID.
List Invoices Returns invoices with Size and From only. Used with List Payments to build an outstanding balance view.

Products

Create Product Adds a product to the price list. Item type depends on an account setting, and JobNimbus syncs a product to QuickBooks only when its name is under 32 characters, so short names matter on a linked account.
List Products Returns the price list with Size and From only. Used to resolve product IDs before building estimate or invoice line items.

Work Orders

List Work Orders Returns work orders and accepts a Size of up to 10000. The `count` it returns reflects every work order in the account rather than the number of records on the current page.
Get Work Order Retrieves a single work order with its line items. Used to reconcile committed work against what has been billed.

Payments

List Payments Returns payments with Size and From only. Joined against invoices in the flow to produce a collections view, since these endpoints cannot filter.

Files

List Files Returns file records with the JSON filter, so everything attached to one job can be pulled with a `related.id` term. The collection comes back under a `files` key.
Upload File Runs the documented three step upload: JobNimbus issues a presigned URL and reserves the record, the bytes are fetched from the supplied File URL and sent to that URL, then the upload is completed and a thumbnail is requested for images and PDFs. The File URL must be publicly reachable, the presigned URL is valid for fifteen minutes, and the endpoint is intended for files under 100 MB.

Frequently Asked Questions

What can FlowRunner do with JobNimbus?

FlowRunner agents can run Create Contact, Update Contact, and Delete Contact in JobNimbus, plus 24 more actions.

Does connecting JobNimbus to FlowRunner require OAuth?

No. JobNimbus connects to FlowRunner with an API key, no OAuth flow required.

Can JobNimbus trigger a FlowRunner workflow automatically?

JobNimbus doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with JobNimbus

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us