Reference · built on requestConnectorField service & CMMS

Simpro

Quotes, jobs, schedules, invoices, and customer assets from Simpro through its per-build REST API and webhook subscriptions.

Request accessPricing ↗

About

Simpro is job management software for trade contractors. Its REST API lives on each customer's build at /api/v1.0/companies/{companyID}/ and covers quotes, jobs with sections and cost centers, schedules, recurring jobs, leads, customers and sites, employees and contractors, catalogs and stock, invoices and payments, customer assets, and plant and equipment. Webhook subscriptions post signed events such as company.customer.updated with a reference block that points back to the record. An OpenAPI 2.0 specification is published for download.

Fibric reads the build's records, follows the webhook references to fetch what changed, and proposes schedule blocks, job notes, and job updates. A scheduler approves each proposal before the PATCH or POST is sent.

This is a reference listing. It documents what Fibric would read from Simpro 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

  • Jobs with sections, cost centers, notes, timelines, and invoices under /api/v1.0/companies/{companyID}/jobs/
  • Quotes, leads, recurring jobs, and contractor jobs, each with their own cost centers and schedules
  • Customers, sites, contacts, employees, contractors, and vendors from the People resources
  • Schedules across jobs, quotes, leads, and activities from the unified /schedules/ resource, up to 1000 per page
  • Invoices, customer payments, credit notes, and vendor orders and receipts
  • Customer assets, plant and equipment, tasks, and work orders / job cards
  • Webhook events such as company.customer.updated, posted with a reference block and an X-Response-Signature header

Proposed actions

  • Target capability: propose a job update through PATCH /jobs/{jobID}, or a job note through POST /jobs/{jobID}/notes/
  • Target capability: propose schedule blocks for a job cost center, or a bulk schedule create through POST /schedules/
  • Target capability: propose archiving a job by sending ArchiveReason in its own PATCH request
  • Target capability: propose a quote or lead schedule change under its cost center
  • Target capability: propose a job invoice through POST /jobs/{jobID}/invoices/

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

What you can build

  • Fill schedule gaps by cost center

    Job cost centers with no schedule blocks are read with their zones and due dates. The operator proposes a block with staff, date, and start and end times; the scheduler approves it.

    With Field Dispatch

  • Keep service intervals on customer assets

    Customer assets and their linked jobs are read from the build. When an interval comes due, the operator proposes a new job with a schedule for approval.

    With Service Interval

  • Follow up quotes before they expire

    Quotes are read with their dates and status codes. The operator drafts the follow-up, proposes the send, and leaves the outcome on the quote for a person to approve.

    With Quote Expiry

  • Watch jobs that stop moving

    Job timelines and status codes are read daily. Jobs with no activity past your threshold are listed, and the operator proposes the next action for approval.

    With Work Order Aging

Requirements

  • A Simpro build whose administrator requests API access under System > Setup > API > Applications, or credentials Simpro has pre-registered across builds
  • The key file for the application: Authentication URL, Token URL, Client ID, and Client Secret
  • A webhook subscription created under System > Setup > API > Webhook Subscriptions with a secret and a callback URL
  • The companyID for each company on a multi-company build; single-company builds use 0
Authentication
OAuth 2.0 against the build's Token URL using the client credentials, authorisation code, or resource owner grants, with Bearer tokens that expire in 3600 seconds; an API key that never expires is also offered.

Limits

  • More than 10 API requests per second against one build returns 429 until the rate drops
  • An authorisation code must be exchanged within 3 minutes, and each refresh invalidates the previous token pair
  • ArchiveReason cannot be combined with other fields; archiving a job takes a separate PATCH
  • List calls return 30 rows by default and at most 250 per page (1000 for /schedules/), so history loads are paced

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 Simpro ↗

Questions and answers

Is there one Simpro API endpoint for all customers?
No. Each customer has a build with its own URL, and the API is reached at that build under /api/v1.0/companies/{companyID}/. Multi-company builds carry a companyID of 0 or higher; other builds use 0. Credentials are issued per build unless Simpro has registered the application across builds.
How are webhooks secured?
You choose a secret when creating the subscription. Each message carries an X-Response-Signature header, an HMAC hexdigest of the request body computed with SHA1 and that secret. Simpro recommends comparing it with a constant-time string comparison.
What happens above 10 requests per second?
Simpro answers every further request against that build with HTTP 429 until the rate falls back under the limit. The documented alternatives are the /multiple/ routes for Post and Patch Multiple, display=all to fetch subresources in one call, and pagination.
Ask about Simpro

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Simpro through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy