Simpro API Integration Guide: Auth, Endpoints, Rate Limits & Patterns (2026)

The Simpro API is one of the more capable field-service management APIs in the Australian market, but the documentation assumes you already understand REST, OAuth, and Simpro's data model. This guide fills the gaps we wish we had known when we shipped our first Simpro integration.

Written for developers evaluating whether to build in-house, and for CTOs deciding whether to hire someone who already knows the platform.

What the Simpro API actually does

Simpro's REST API exposes almost everything the Simpro web UI does, jobs, quotes, invoices, customers, sites, employees, catalogues, cost centres, timesheets and reporting. If you can see it in the Simpro interface, you can read or write it via the API.

What it does not do (as of mid-2026):

• Real-time webhooks. No native push notifications for events like "job status changed" or "invoice created". You poll or nothing.
• Bulk operations. Every create/update is a single-record call. Batching 500 records means 500 HTTP requests.
• Historical audit trail beyond a limited window. If you need who-changed-what-when for compliance, you need to record it yourself as you sync.

Authentication (OAuth 2.0)

Simpro uses OAuth 2.0 with the client credentials flow for server-to-server integrations. The steps:

1. Get your customer to create an API user in their Simpro build under System → Setup → API, you cannot create it for them.
2. They generate a client ID and client secret for the API user.
3. You exchange those for an access token against https://{their-build}.simprosuite.com/oauth2/token.
4. Every subsequent API call goes to https://{their-build}.simprosuite.com/api/v1.0/companies/{company-id}/....

Access tokens expire in 1 hour. Store the expiry timestamp with the token and refresh proactively, do not wait for a 401 to trigger a refresh in production.

Core endpoints most integrations use

Rate limits and pagination

Simpro rate limits are documented as 200 requests per minute per API user. In practice we have seen bursty patterns triggering earlier throttling. Assume:

• Bake in exponential backoff on 429 responses (Simpro returns Retry-After, respect it).
• Do not parallelise more than 4 concurrent requests to the same build.
• Cache reference data (cost centres, catalogue items, tax codes), do not hit the API for these on every sync.

Pagination is the source of most Simpro integration bugs. The API returns paginated collections with page and pageSize query params. The default page size is small (25). Common bugs:

• Reading only page 1 and assuming that is the full dataset (this passes acceptance testing on a demo build with 20 jobs, fails in production with 2,000)
• Not handling the case where new records are added mid-pagination (record N+1 you see on page 2 was on page 1 five seconds ago)
• Sorting order changes between pages if you do not specify an explicit orderby

Common integration patterns

Pattern 1: Simpro → Xero invoice sync

Most common integration by far. Poll GET /invoices?DateIssuedSince={last-sync}, transform to Xero's invoice schema, POST to Xero. Watch for:

• Simpro tax codes → Xero tax rates mapping (not 1:1, needs a lookup table you configure per customer)
• Progress claims and retention (Simpro handles these as separate invoice types)
• Credit notes (Simpro allows partial credits with different reason codes)

Pattern 2: Job → payroll timesheet sync

GET /timesheets filtered by date range, transformed to your payroll platform's schema (Deputy, Employment Hero, MYOB Payroll, Xero Payroll). See our rostering-to-MYOB compatibility guide for platform-specific mapping notes.

Pattern 3: Two-way customer sync

Customers can be created in either Simpro or your CRM. Two-way sync needs:

• A stable external ID stored on both sides (Simpro custom fields work well)
• Conflict-resolution policy (last-write-wins is dangerous, usually one system is authoritative for a given field)
• Deduplication logic (email + business name is more reliable than either alone)

Gotchas we have seen in production

• Time zones. Simpro stores dates in the build's local timezone but the API returns them without offset. If your integration runs in a different timezone, off-by-hours errors sneak in.
• Deleted records. Deletes do not appear in DateModified filters. If a job is deleted in Simpro, you will not detect it unless you compare the full ID list.
• Cost centre changes. A cost centre renamed in Simpro keeps the same ID, but any downstream system doing a name-based join will silently break.
• Sandbox drift. Simpro sandboxes do not stay in sync with production. Test on a copy of real data before go-live, not just the sandbox.

When to build vs when to hire

You can build a working Simpro → Xero invoice sync in a week of focused developer time. The maintainable version, the one that handles pagination correctly, retries safely, logs failures where someone will actually see them, and survives Simpro API version bumps, takes 3-6 weeks depending on scope.

Reasons to hire out:

• Multiple downstream systems (Simpro → Xero AND payroll AND Power BI)
• Compliance stakes (STP2, GST, audit trails)
• You need it done in a fixed timeframe with a fixed price
• The internal dev team has other priorities and this is the third integration this quarter

If you want a scoped conversation, our Simpro integration services page covers the workflows we build for Australian trade businesses and the fixed-price model we use.

Kasun Wijayamanna Founder & Lead Developer

Postgraduate Researcher (AI & RAG), Curtin University - Western Australia

View profile →