SimPRO Webhooks vs Scheduled Syncs

When two systems need to stay aligned with SimPRO, one early design decision is how the integration discovers a change. The usual choices are an event-driven webhook, a scheduled API sync, or a combination of both.

There is no universally correct answer. The right choice depends on how quickly the business needs the update, which events are available, how missed events are recovered and how much data must be checked.

When webhooks are useful

Webhooks notify an application when a supported event occurs. They are a good fit when a downstream workflow should react quickly without repeatedly checking for changes.

Examples include:

• Starting a follow-up process after a record changes.
• Notifying another platform that new work is available.
• Adding an event to a queue for validation and processing.

The receiving endpoint should acknowledge the event quickly, store the important identifiers and hand the real work to a background queue. It should not attempt a large synchronisation inside the webhook request.

Webhooks still need recovery

An event can be delayed, delivered more than once or fail before the receiving application stores it. Webhook processing should therefore be idempotent: receiving the same event twice must not create the same job twice.

A periodic reconciliation process is also useful for checking that important records have not been missed.

When scheduled syncing is simpler

A scheduled job can ask the API for records changed since a known timestamp. This works well when updates do not need to be immediate or when the required change is not represented by an available webhook.

Scheduled syncs need:

• A reliable cursor or last-successful timestamp.
• Pagination for larger result sets.
• Overlap to handle records updated near the boundary.
• Duplicate-safe processing.
• Monitoring that shows when a schedule stops producing results.

A hybrid approach

Many dependable integrations use webhooks for speed and scheduled reconciliation for completeness. The webhook queues a specific record quickly; the scheduled process periodically checks that the wider dataset still agrees.

Both routes should call the same application service so validation and business rules do not diverge.

Questions to decide the approach

1. How quickly must the other system know about the change?
2. Is a suitable SimPRO event available?
3. Can the process safely receive the same update twice?
4. How will missed events be discovered?
5. Who needs to see delayed or failed updates?

The transport mechanism is only one part of a reliable SimPRO API integration. The recovery and visibility around it usually matter more.