Jobber API Rate Limits: What You Can Actually Build, Measured in Production

Search “jobber api” and Jobber’s own developer docs take the first four results and the AI answer box. Fair enough, they are decent docs. What they never tell you is what will not fit inside the limits, because vendor docs describe what exists, not what breaks.

Here is the two-sentence version. Jobber has one API: a GraphQL API, managed through Jobber’s Developer Center, available on the Plus plan. Every query you send is metered two ways at once, by query cost and by request count. Some reasonable things owners ask for do not fit inside those meters.

We build Jobber integrations for a living. One of them is a KPI dashboard for a Jobber shop, running in production, with logging on every API call. The numbers below come from those logs, not from reading the docs. Our honest guide to Jobber integrations covers which tier of integration you need. This post is the layer underneath: the exact limits, and what you can actually build against them.

Every Jobber API limit in one table

Sources: Jobber’s API rate limit documentation, plus our own production measurements, 2026. Last verified 2026-08-14. Jobber has not paid us and does not know we are writing this.

How the cost bucket actually works

Jobber’s primary limiter is not “requests per minute.” It is a query cost budget. Each GraphQL query gets a point cost calculated from what it asks for: more fields, more nested records, more rows per page, higher cost.

The bucket holds 10,000 points per app and account pair. It refills at 500 points per second. Send nothing for 20 seconds and you are back to full.

That sounds generous until you price a real workload. A query that pulls a page of jobs with their line items, visits, and invoice status is not a cheap query. Stack 40 of those into one screen and you have spent more than the bucket holds.

What one real dashboard load costs

The dashboard we run for one Jobber shop pulls jobs, visits, invoices, and payments to compute the owner’s weekly numbers. With per-call cost logging turned on, a single dashboard load measured 13,456 to 20,762 query-cost points across 41 to 52 API calls.

The budget is 10,000.

So one load of one dashboard for one user exceeds the entire bucket, on the low end by a third, on the high end by more than double. This is a real log line from that system:

Jobber throttle bucket low: 438/10000 points available

That is 438 points left out of 10,000, mid-load, with calls still queued. The naive version of this dashboard, “query Jobber when the page opens,” throttles itself before the page finishes rendering. Not on a bad day. Every time.

The fix is architectural, not clever retry code. The dashboard cannot read from Jobber at load time. It reads from its own database, and a background worker syncs that database from Jobber on a schedule, paced under the 500 points per second refill. Jobber’s rate limits are effectively a design requirement: any reporting integration becomes a sync pipeline plus a local store, whether you planned one or not.

The second limiter, and why webhooks make it worse

Even if your queries are cheap, there is a separate cap: 2,500 requests per 5 minutes, about 8 per second sustained. Two features of the API push you toward it faster than you would guess:

• Webhooks carry only an ID. Jobber tells you “invoice 12345 changed” and nothing else. Every single webhook costs a follow-up query to fetch the record. A busy Monday at a 15-crew shop, with dispatchers rescheduling and invoices going out, turns into a burst of webhooks, and your follow-up queries eat both limiters at once.
• There is no delta sync for visits. The Visit type has no updatedAt field. You cannot ask “which visits changed since last night.” If visits matter to your integration, and for scheduling work they always do, you re-pull them and diff on your side. That is more requests and more points, spent on data that mostly did not change.

The trap that gets every off-the-shelf client

When Jobber throttles you, the response is HTTP 200 with a THROTTLED error in the GraphQL body, not a 429 status.

This matters because nearly every retry library, HTTP client, and integration platform keys its backoff on status codes. A 200 means success to all of them. So a throttled integration built on standard tooling does not slow down. It keeps firing, keeps getting empty-handed 200s, and whatever was reading its output sees data quietly stop arriving. No error page, no alert, just numbers that stop updating.

Handling this correctly means parsing every response body for the THROTTLED error and treating it as a rate signal. It is not hard. It is just something nobody does until it has cost them a weekend.

So what can you actually build?

The pattern across every row: the API is complete, but it is not fast, and it is not free-form. Anything that reads a lot of data has to become a paced pipeline with local storage. Anything event-driven has to budget a follow-up query per event. Once you design for that, the API holds up fine in production. We know because we run systems on it every day.

If you are scoping a build

Two honest checks before you spend money. First, confirm you are on or budgeting for the Plus plan, because the API does not exist below it. Second, if what you want is report-shaped, assume a sync pipeline from day one, and treat anyone who quotes you a “simple live dashboard” as someone who has not read their own logs. If the data you need is small and event-shaped, the build is genuinely small. And if all you need is your data in a spreadsheet, check the non-API routes first: we compared every one in how to export data from Jobber.

This is the work we do. Our custom Jobber reports and dashboards page covers what we build against this API, sync pipelines and crew calendars included. Or book a discovery call and bring the thing you want built. If it fits in a Zap, we will say so and save you the budget.