Simpro API Guide for Contractors

One-line verdict: A deep, documented REST API with webhooks and five ways to sign in — arranged one customer build at a time, by that build’s admin. Openness: 4 / 5 — rated 4 because Simpro documents a full REST API with OAuth, a published endpoint reference, and a webhook system, held back from 5 by the per-build, admin-mediated setup and an entity matrix that’s only partly verifiable from public pages. (Name note: the vendor now styles it Simpro; older pages and its API forum still say “simPRO.”)

The connection that works

Rung 1 — Direct connection. Simpro’s developer center states it directly: “Our RESTful API allows you to view, create or edit resources on any Simpro builds,” designed to the Swagger/OpenAPI 2.0 specification with a downloadable spec and a full endpoint list. Read that sentence’s key phrase twice: on any Simpro builds. Each customer runs their own build of Simpro, and API access is arranged per build — there is no single central door.

Authentication is the most flexible in this directory: five documented grant types — authorization code and implicit (“Log in with your Simpro account”), resource-owner credentials, client credentials (which Simpro calls the more secure option), and a plain API key described as “a single access token which never expires.” That last one deserves an owner’s attention: a key that never expires is convenient and dangerous in equal measure — lose it and it works forever until someone revokes it. After choosing a grant, the application gets registered.

Verified at the endpoint level: Customers — list all customers and company customers (paged, up to 250 per page), and create a new company customer — is documented in the reference. The developer center’s general claim covers jobs, quotes, invoices, and payments as “resources,” and Simpro’s own API forum (staff answers) references job, quote, lead-conversion, and customer-invoice routes — but forum posts are weaker evidence than the reference, and several per-object reference pages wouldn’t render in our pass, so the entity-by-entity read/write matrix for those objects stays UNVERIFIED below rather than extended from the customers proof.

Webhooks: documented properly — subscribe to events instead of polling, with subscriptions set up by an administrator inside the build (System → Setup → API → Webhook Subscriptions) or created through the API itself; payloads are signed (SHA1 HMAC in a header) with a secret you choose. The documented example event is a customer update; the full event catalog wasn’t extractable in our pass.

Plan gate: Simpro’s pricing page presents a single base plan and checkmarks “Open API” under its available integrations — no API add-on is stated. Bridge apps: Zapier carries a Simpro app (bridge evidence: New Job and New Company Customer triggers; Create Service Job among the actions). No native Make app was verified.

Can automate

• Customer sync, proven — customer lists can be pulled and company customers created through documented endpoints, so Simpro and your CRM can stop disagreeing.
• Event-driven follow-up — admin-set webhook subscriptions mean changes inside a build can start work elsewhere, signed so you know they’re genuine.
• Service-job intake through the bridge — Zapier templates create service jobs from form entries (bridge evidence).
• Per-build control — credentials live with each build, so a multi-entity operation can grant access company by company.

Can’t automate

• A verified per-object matrix for jobs, quotes, invoices, and payments — UNVERIFIED endpoint by endpoint in this pass. The general “view, create or edit resources” claim is verified; the individual verbs are not. Scope any quote object by object against the reference.
• Customer update/delete — UNVERIFIED. List and create-company-customer are verified; the further operations on that page weren’t individually confirmed.
• The full webhook event catalog — UNVERIFIED (the customer-updated example is documented; the complete list wasn’t extracted).
• A numeric rate limit — UNVERIFIED. None was found in the vendor pages extracted. (The 250 figure under Customers is a page-size cap, not a rate limit.)
• A key that forgives carelessness — the never-expiring API key is documented; treat it like a master key, because functionally it is one.

Hidden gate: Every customer’s Simpro is its own separate build — their admin has to set up API access and hand over credentials first. There is no central switch, and a multi-build group repeats the setup for each company.

Build fit — what this platform supports well

• Back-office and customer sync — the proven surface: customers in and out, events out, per build.
• Speed-to-Lead — workable: the vendor’s customer type even includes “Lead,” and service jobs can be created from intake tools through the bridge; endpoint-level lead writes stay UNVERIFIED.
• Estimate Follow-Up / Invoice Chase — pattern-level only: quotes and invoices are named resources, but their verbs are UNVERIFIED — verify before quoting.
• Review Engine — like every platform here, Simpro has no verified reviews API (its pricing page lists Podium as an integration — a partner listing, not an endpoint), so the review ask runs on our system triggered by a job-completion signal.

What this means for your shop

If you run Simpro — typically a larger electrical, plumbing, HVAC, or security operation — you own a genuinely documented API with real events and flexible sign-in. The work is governance: per-build credentials, an admin who owns the webhook subscriptions, and a hard rule about that never-expiring key. Get those three right and Simpro connects as deeply as anything in this directory.