FreshBooks API Guide for Contractors

One-line verdict: The whole estimate-to-invoice-to-payment chain, readable and writable through one documented API — with a review gate only if your builder wants to sell the app to everyone else. Openness: 4 / 5 — rated 4 because FreshBooks documents a REST API with OAuth sign-in, per-object read/write scopes, and a full webhook catalog, held back from 5 by the AppStore review for public apps and a rate limit the vendor states only in words, not numbers.

The connection that works

Rung 1 — Direct connection. FreshBooks documents a REST API with OAuth 2.0 sign-in — the authorization-code flow, no API key — where you create an app in its Developer Hub and choose scopes at creation. The scope model is the clearest in this directory: every object carries user:<object>:read and user:<object>:write, and FreshBooks defines write plainly as “modifying the resource in any way (creating, editing, archiving, or deleting).” The documented object list covers the money chain a small shop lives on: clients, estimates, invoices, payments — each verified read and write (create, update, get, list; delete for clients, estimates, and payments) — plus projects, bills, credit notes, expenses, and time entries. (Current-product note: these claims are for the modern FreshBooks platform, checked against the vendor’s own Classic-migration table — the retired FreshBooks Classic is a different animal.)

One operational discipline, vendor-documented: if the app’s scopes ever change, every user has to re-authorize. Pick the permission list carefully the first time.

Webhooks: a documented catalog in noun.verb form (invoice.create, estimate.sendByEmail, and kin) spanning clients, estimates, invoices, payments, projects, expenses, and more. Callbacks must complete a verification-code handshake before notifications flow, deliveries are signed, non-2xx responses retry — and FreshBooks states honestly that delivery speed is not guaranteed: “a few seconds to several minutes.”

Limits: also stated honestly, in the other direction — “there are no limits on the number of API requests per day,” but requests “will be rate-limited if too many calls are made within a short period,” and list calls return at most 100 results. No numeric rate is published, so none is promised here.

The review gate: it applies to public apps. An app that reaches other customers goes through the FreshBooks AppStore — published requirements (OAuth, consent-screen scopes, efficient API use, backing off on a 429) and a Submit-for-Review step. A private app for your own account needs no review on the evidence we found. Bridge apps: both Zapier and Make list FreshBooks apps (bridge evidence) — convenience routes on top of a real API.

Can automate

• Estimate Follow-Up — estimates are full API objects that can be created, sent, and accepted; the follow-up can key off the estimate itself, not a workaround.
• Invoice Chase / AR — invoices and payments are readable and writable, with webhook events — the strongest small-shop money chain in this directory alongside QuickBooks.
• Client sync — clients can be created and maintained from your intake tools, so the books and the pipeline share one list.
• Project and time visibility — projects and time entries are scoped API objects, so job costing outside FreshBooks reads real numbers.

Can’t automate

• A CRM pipeline — it doesn’t exist here. No deals object appears in the documented scope list. FreshBooks is accounting with projects, not a sales pipeline; don’t let a quote model it as one.
• A numeric rate budget — UNVERIFIED. The vendor publishes no number. Builds should pace politely and honour the 429.
• A plan minimum — UNVERIFIED. No plan tier is named as the API tier in the vendor docs we checked; the creation flow starts from any trial or paid account. (Some account levels cap client counts — a capacity note, not an API gate.)
• Instant webhooks, guaranteed — the vendor itself quotes seconds-to-minutes. Design follow-up for “fast,” not “instant.”

Hidden gate: Your builder’s app only reaches your customers after FreshBooks reviews the AppStore listing — and if the app ever needs a new permission, every user has to click Allow again. Your own private connection skips the review; it does not skip the scope decision.

Build fit — what this platform supports well

• Invoice Chase / AR — the strongest fit: the full chain is documented, writable, and event-backed.
• Estimate Follow-Up — strong: estimates are first-class objects with send and accept operations.
• Speed-to-Lead — indirect: leads live in your CRM or intake tool; the client record lands in FreshBooks when the work is won.
• Review Engine — like every platform here, FreshBooks has no verified reviews API, so the review ask runs on our system triggered by a job-completion signal — a payment or project webhook supplies it.

What this means for your shop

If FreshBooks runs your books — common for solo operators and small service shops — your money automation has a clean, documented road: estimate, invoice, payment, all reachable, all eventful. The two things to manage are scope choices (re-authorization is a nuisance you only want once) and webhook patience (minutes, not seconds). Everything else is as open as accounting software gets.