Jobber API: what it can do, where it stops, and what's worth building on it

Owners ask about the Jobber API for one of two reasons. Either they want data out of Jobber that the built-in screens and reports will not give them, or they want Jobber to talk to another system without someone retyping everything. This page covers both in plain words, then gets specific about the limits, so you can decide whether a build is worth it.

You do not need to read code to follow it. Everything here comes from Jobber's own Developer Center and help center as of 27 October 2026.

Does Jobber have an open API?

Yes. Jobber publishes full developer documentation at developer.getjobber.com, and anyone can sign up for a developer account. A few basics, translated:

• It is a GraphQL API. Instead of many fixed web addresses, there is one address, and each request asks for exactly the fields it needs. Reads are called queries and writes are called mutations.
• It uses OAuth 2.0, not API keys. There is no key to copy from your settings. Instead, a Jobber admin approves an app the same way you approve "Sign in with Google," and sees what it is asking for. Access tokens last 60 minutes and are renewed with a refresh token.
• It is versioned. Every request names a version in a header. Jobber supports old versions for at least 12 months, and they stay reachable for up to 18 months from release, so a build needs a small amount of upkeep each year.

What can the Jobber API access?

The API covers the core records of a service business:

• Clients and properties
• Requests, quotes and jobs
• Visits and timesheet entries
• Invoices and expenses
• Products and services
• Users and the account itself

What an app can read or change depends on its scopes, the permissions listed on the screen when you connect it. An app that only needs to read invoices for a report should only ask for that. If an app adds scopes after it is published, every existing user has to approve it again.

Jobber also supports app-configured custom fields, so an integration can store its own data, such as an external ID or a job category, on Jobber records.

How do Jobber webhooks work?

A webhook is a message Jobber sends to your system the moment something happens, such as a new client, an approved quote or an updated invoice, so your system does not have to keep asking. Webhooks are set up per app in the Developer Center, and topics follow a pattern like CLIENT_CREATE or INVOICE_UPDATE.

Jobber's documentation is unusually specific about how they behave, and it matters for anything you build:

• The message is a pointer, not the data. It says what happened and which record, and your app then asks the API for the details.
• Your system must answer within 1 second. If responses are slow or failing too often, Jobber may switch off that app's webhooks.
• Messages can arrive twice. Delivery is "at least once," and some actions fire the same topic twice in quick succession. Adding a payment to an invoice, for example, sends two invoice-update messages.
• Nobody warns you if they stop. Jobber does not send alerts for failed webhook deliveries, so the app has to watch itself.

None of this is hard for an experienced developer, but it is the difference between an integration that runs quietly for years and one that double-counts payments.

What are the limits of the Jobber API?

Rate limits

Jobber applies two limits to each app on each Jobber account:

• 2,500 requests per 5 minutes. Go over and further requests get a "429 Too Many Requests" error until the window resets.
• A query cost budget. Each app and account pair has up to 10,000 points, which refill at 500 points a second. Every query costs points based on how much data it asks for, and a query that would cost more than what is left gets a "Throttled" response.

For a single business, these limits are comfortable. They matter mostly for the first full copy of several years of history, which a good developer pulls in smaller pages over a longer run rather than in one large request.

Private apps versus Marketplace apps

This is the limit most write-ups miss, and the one that matters most to a business owner. Jobber's documentation says its current focus is on integrations that will be launched in its App Marketplace. A custom integration, meaning an app built for one business that is never listed publicly, is "only possible for specific, approved Jobber customers and developers."

A custom integration uses the same scopes and sign-in as any other app and can do the same things. It stays in Draft state, which does not need Jobber's app review, but a Draft app is blocked if it connects to more than 5 paying Jobber accounts. Apps going into the Marketplace go through Jobber's review, must handle disconnects properly, and can be rejected for asking for more scopes than they need.

In practice: before anyone builds a private integration for you, contact Jobber's API support and confirm your account can use one.

What Jobber will not list

Jobber publishes a list of app types it will not approve for public Marketplace listing: payment processing, financing, lending, insurance, debt collection, and full MCP integrations (the kind of connection that lets an AI assistant run your whole account).

Testing and plans

Jobber's developer guide offers a free developer testing account that runs for 90 days without a subscription prompt, and can be extended by emailing Jobber's API support. The developer docs do not tie API access to a particular paid plan. Zapier, by contrast, is only on select plans, so check the gear icon, then Account and Billing, for your own.

What can you build with it?

These are the projects that come up most often for service businesses:

• Custom reports and dashboards. Pull jobs, visits, invoices, expenses and timesheets into one view and show profit per job, per crew and per month. Join it with QuickBooks to put real costs next to income. This is the most common project, because Jobber's built-in reports cannot join its data with anything else. See my Jobber reporting guide for exactly what is missing.
• A client portal. Give commercial clients or property managers a login where they see their sites, visits, quotes and invoices, and send new requests that land in Jobber. More on this in my client portal guide.
• A website quote form. A calculator on your site that creates the client and the request inside Jobber, so nothing is retyped. See instant quote software.
• Automations with your own rules. When a quote is approved, create a task elsewhere and text the crew lead. When a job closes, ask for a review, but only for clients who have not been asked this year.
• Links to other systems. Send timesheets to payroll, invoices to your accounting tool, or job data to an internal dashboard. My internal tools guide covers the wider picture.
• AI workflows with a human check. Let AI read a new request and draft a reply or a quote, which someone approves before it goes out.

Can I use Jobber's Claude and ChatGPT connector instead?

For some jobs, yes. Jobber now has its own connector for Claude and ChatGPT, available on Core, Connect, Grow and Plus, set up from the App Marketplace with no technical work. Once connected, you can ask the assistant to look up clients, properties, requests, quotes, jobs and invoices, create or edit requests, clients and properties, and draft new quotes.

It has firm limits. It cannot create or edit jobs or invoices, cannot edit a quote once created, cannot delete or archive anything, and cannot manage the schedule. It is good for quick questions and for turning an email into a request. It is not a report, a portal or an automation that runs on its own.

Can I use Zapier instead of the API?

Often, for simple one-step jobs. Jobber's Zapier integration is on select plans. These Jobber events can start a Zap: new client, client updated, new request, new quote, quote sent, quote approved, new job, job completed, job updated, new invoice and invoice updated. Zapier can also do these things in Jobber: create a client, add tags to a client, create a request, add a note to a request, create a quote, or create a job.

The limits Jobber lists are worth knowing before you rely on it:

• Create Request, Create Quote and Create Job always use the client's first property if the client has several.
• The Client Updated trigger does not fire for new notes or new properties.
• If the team member who connected Zapier is deactivated in Jobber, the connection drops and has to be reconnected.
• The number of Zaps and runs depends on your Zapier plan, which is billed separately.

Zapier fits "when this happens, do that." The API fits reports, portals and anything with your own business logic.

How do I export my data from Jobber?

For a client list, no code is needed:

1. Open the Clients tab.
2. Choose More Actions, then Export Clients.
3. Pick CSV or vCard, and optionally filter by tag. If you pick several tags, only clients with every one of them are included.
4. Jobber emails you the file. Large CSV exports are split into files of up to 1,500 rows.

The export includes tags, property addresses, contact details and custom fields. Admins have full import and export, and the feature depends on your plan. Individual reports can be exported as CSV too, and Jobber's free Report Scheduler app can email some of them on a schedule. For jobs, invoices and the rest of your history in one complete copy, the API is the route.

When should I build on the Jobber API?

Build when the gap is clear and a spreadsheet no longer fixes it. Good signs:

• Someone rebuilds the same weekly report by hand from exports.
• Customers ask for updates your office types out one by one.
• Data lives in Jobber and one other system, and someone copies between them.
• You want AI to act on Jobber data, with a person approving the result.

Skip the build if Zapier or the Claude and ChatGPT connector already covers it, or if a plan upgrade unlocks the feature you are missing. My Jobber pricing guide shows what each plan adds and what it costs.

How I'd approach this

I start with the question you are actually trying to answer or the job you are trying to stop doing by hand, not with the API. If Zapier or Jobber's own connector covers it, I will tell you to use that. If it does need a build, the first step is confirming with Jobber that your account can run a private integration, before any code is written.

Then I keep Jobber as the place your team works and build the missing piece next to it: usually a dashboard or a weekly summary that reads your Jobber data and joins it with QuickBooks or payroll, or a small portal for your commercial clients. I build it to respect the rate limits, handle duplicate webhooks and survive API version changes, and it runs in accounts you own, so you keep the code and the data either way.