Reference · built on requestConnectorField service & CMMS

Jobber

Clients, quotes, jobs, visits, and invoices from Jobber through its GraphQL API and per-app webhooks.

About

Jobber is business management software for home service companies. Its API is GraphQL over HTTPS: every request is a POST to https://api.getjobber.com/api/graphql with a Bearer token, a Content-Type of application/json, and an X-JOBBER-GRAPHQL-VERSION header naming a dated schema version. The schema covers clients, properties, requests, quotes, jobs, visits, invoices, users, time sheet entries, and expenses. Each object carries a base64 EncodedId, and every response reports its query cost.

Fibric queries that schema, subscribes to webhook topics per app, and fetches the changed object by itemId when a topic arrives. An operator proposes a quote follow-up, a visit change, or a new client, and a person approves it before the mutation runs.

This is a reference listing. It documents what Fibric would read from Jobber and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Clients, properties, requests, quotes, jobs, visits, and invoices through GraphQL queries at https://api.getjobber.com/api/graphql
  • Users, time sheet entries, expenses, assessments, and products or services from the same schema
  • Webhook topics named OBJECT_ACTION, such as CLIENT_CREATE and INVOICE_UPDATE, delivered as a POST with topic, accountId, itemId, and occurredAt
  • Query cost and throttle status from the extensions.cost block on every response
  • APP_CONNECT and APP_DISCONNECT events, so access is dropped the moment an account disconnects
  • Cursor pagination through pageInfo.hasNextPage and endCursor, with totalCount on collections

Proposed actions

  • Target capability: propose a new client through clientCreate; Jobber records your app's name as the client's Lead Source
  • Target capability: propose changes to quotes, jobs, visits, and invoices through the schema's mutations, reading userErrors before reporting success
  • Target capability: propose disconnecting an account through appDisconnect when credentials are rotated

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Follow up quotes before they go stale

    Quotes are read with their status and sent date. The operator drafts the reminder, proposes it for approval, and records the outcome on the quote.

    With Quote Follow-up

  • Remind clients ahead of a visit

    Upcoming visits and their properties are read from the schema. The operator drafts the reminder and proposes the send; a person approves it before it leaves.

    With Appointment Reminder

  • Answer new requests within the hour

    When a request topic arrives, the operator fetches the request by itemId, drafts the first reply, and proposes it for approval.

    With Lead Response

  • Chase overdue invoices

    Invoices and their balances are read on a schedule, and INVOICE_UPDATE topics mark payments. The operator proposes the next reminder step for approval.

    With Dunning Cadence

Requirements

  • An app created in the Jobber Developer Center with a client ID, client secret, OAuth callback URL, and only the scopes it needs
  • A company admin on each Jobber account who clicks Allow Access on the authorization page
  • An active X-JOBBER-GRAPHQL-VERSION date on every request; versions are supported for at least 12 months
  • A webhook endpoint that answers within 1 second and verifies the X-Jobber-Hmac-SHA256 header with the client secret
  • App Review before listing in the Jobber App Marketplace, or a private integration connecting no more than 5 paying Jobber accounts
Authentication
OAuth 2.0 authorization code grant with PKCE (S256), authorized by a company admin for each Jobber account; access tokens last 60 minutes and are renewed with a rotated refresh token.

Limits

  • Query cost is capped at 10,000 points per app and account pair, restored at 500 points per second; a query above the cap never resolves
  • 2,500 requests per 5 minutes per app and account; beyond that Jobber returns 429 Too Many Requests
  • Webhook payloads carry only the item id and topic; the object itself is fetched with a follow-up query
  • Delivery is at least once, and one user action can fire the same topic twice; the connector deduplicates by itemId and topic

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Jobber ↗

Questions and answers

Is the Jobber API REST or GraphQL?
GraphQL. All requests are POSTs to a single endpoint, https://api.getjobber.com/api/graphql, with a Bearer token, Content-Type: application/json, and an X-JOBBER-GRAPHQL-VERSION header. Only JSON bodies are accepted. Queries read data; mutations create, update, or delete it and return a userErrors array to check.
How does Jobber throttle requests?
Two ways. A query cost limit gives each app and account pair 10,000 points, restored at 500 points per second, with the cost reported under extensions.cost. A request limit allows 2,500 requests per 5 minutes per app and account, after which Jobber returns 429 Too Many Requests.
Do webhooks include the changed record?
No. The payload names the topic, appId, accountId, itemId, and occurredAt. Your endpoint acknowledges within 1 second, verifies the X-Jobber-Hmac-SHA256 header with the app's client secret, and queries the API by itemId for the object. Delivery is at least once.
Ask about Jobber

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.