Short answer
The Simpro API is a REST API reached at each customer's own build URL, covering customers, jobs, quotes, scheduling, materials and invoicing. It supports several OAuth 2.0 grants and non-expiring API keys; a customer's admin registers your app in their build, or you become a Simpro Integration Partner. The limit is 10 requests per second per build. If the goal is an AI assistant working with field service data rather than a system-to-system integration, an MCP server is the faster route.
Authentication
OAuth 2.0 (authorization code, implicit, resource owner, client credentials) or an API key that never expires. OAuth access tokens last an hour with rotating refresh tokens. For a single customer, their admin registers your app inside their build; Integration Partners get one set of credentials that works across builds.
Getting access
- Work with one Simpro customer whose admin requests API access for your app, or become a Simpro Integration Partner.
- Partners test in a Simpro sandbox and demo the app to Simpro before credentials are issued.
- Plan requirements and fees: not published in the developer docs.
What you can reach
- Customers, contacts, sites, employees, contractors, vendors
- Jobs, cost centers, recurring jobs, leads, quotes
- Catalogs, inventory, prebuilds, vendor orders
- Invoices, payments, credit notes, recurring invoices
- Schedules, activities, tasks, work orders, zones, teams
- Custom fields, tax codes, status codes, webhook subscriptions, assets, plant and equipment
Webhooks, rate limits and test environment
| Simpro | |
|---|---|
| Webhooks | Yes, signed (HMAC-SHA1): customers, job stages, schedules, attachments, notes, invoices, purchase orders, recurring jobs and invoices, contracts and assets. |
| Rate limits | More than 10 requests per second from one integration to one customer build returns HTTP 429. |
| Sandbox / test environment | Yes, for partner-level integrations. |
Known limitations
From Simpro's published documentation:
- Every customer is a separate build URL, so multi-customer apps authenticate per build
- Non-partner apps must be set up by an admin inside each customer's build
- OAuth scopes are not used; authorization codes must be exchanged within 3 minutes
Building on the API versus connecting AI through MCP
If you want an integration (syncing Simpro with another system), the API is the route. If you want your team to ask an AI assistant about jobs, schedules and invoices, or have it do the work, you would be building and hosting that yourself on top of the API.
Fieldproxy takes the other route: its official MCP server gives Claude, ChatGPT and Microsoft Copilot 145 field service tools directly, with scoped access and a confirm step before every change, and it can also change the software itself (fields, screens, automations) in a sandbox.
| Build on the Simpro API | Fieldproxy MCP server | |
|---|---|---|
| Time to first answer in ChatGPT or Claude | Build, host and maintain a server | Add a connector and sign in |
| Auth and permissions | You implement them | Per-person sign-in, scopes, row and column limits |
| Changes to data | Raw API writes | Proposed, confirmed by a person, undoable |
| Changing the software itself | Not available through an API | Fields, screens, automations, in a sandbox |
Sources
Read from the vendor's own developer documentation on September 27, 2026. Anything the docs do not publish is marked "not published".
Fieldproxy facts on this page come from the Fieldproxy MCP reference. Competitor details are from each vendor's own documentation as of September 27, 2026; see the comparison table and sources.