Maintenance management API: webhook versus polling for work order updates

ERP Infor CloudSuite
, , , , , , , ,
1

Looking for insights on the best approach to track work order status changes in CloudSuite Maintenance Management (ICS 2022). We need to notify our mobile technician app when work orders are assigned, updated, or completed.

Webhook approach is event-driven and seems more efficient, but I’m concerned about reliability if our endpoint goes down. Polling increases load on CloudSuite by checking every few minutes, but it’s simpler to implement. Reliability varies between the two - webhooks depend on network stability while polling is more predictable.

What method has worked better for real-world work order tracking scenarios? Our facility has about 150 active work orders at any time with status changes throughout the day.

system 2

Both patterns are viable for CloudSuite Maintenance Management work order tracking at your scale. The right choice hinges on your tolerance for implementation complexity versus operational reliability risk.

Criteria Comparison

Criteria Webhook (Event-Driven) Polling
Latency Near real-time (<1s typical) Interval-bound (your polling frequency)
CloudSuite API load Low — triggered only on state change Cumulative — every interval regardless of activity
Implementation complexity Higher — requires endpoint management, retry logic, signature validation Lower — standard REST loop against WorkOrder or MaintenanceWorkOrder ION API endpoints
Reliability risk Endpoint downtime = missed events unless retry/queue layer exists Predictable; missed window catches up on next poll
Ordering guarantees Event ordering not guaranteed under burst conditions Controlled by query sort (e.g., LastModifiedDate ascending)
Scalability beyond 150 WOs Scales well; load stays flat as volume grows Poll cost grows linearly with WO volume and frequency
Infrastructure dependency Requires stable public/private endpoint + TLS cert management Only requires outbound connectivity from your app

Webhook Considerations for CloudSuite

CloudSuite exposes event publication through ION (Intelligent Open Network). Work order status changes can be surfaced via ION BOD (Sync.MaintenanceWorkOrder) events published to a configured ION API connection point. Your mobile app backend subscribes as an ION connection point and receives BODs on state transitions.

Critical gap to address: ION does not guarantee delivery if your endpoint is unavailable during the event window (verify retry behavior in your version). You need a message buffer — an Azure Service Bus, AWS SQS, or equivalent queue sitting in front of your endpoint absorbs spikes and survives downtime. Without this, webhooks carry real data-loss risk in production.

Polling Considerations

Polling against the IFS REST API or ION API using a LastModifiedDateTime filter is straightforward and resumable. At 150 active WOs, a 2–5 minute interval is unlikely to generate meaningful API load. Store the last-successful poll timestamp in your app; on restart you resume without gaps.

The practical downside is notification lag. If a technician is assigned a critical WO, a 5-minute window before the mobile app reflects that is operationally acceptable for many facilities — but not all.

Hybrid Pattern (Worth Considering)

Several production implementations use webhooks as the primary path for low-latency notification, with a scheduled reconciliation poll (e.g., every 15–30 minutes) to catch any events missed during endpoint downtime. This gives you real-time UX with a polling safety net, at the cost of maintaining both code paths.

Ultimately this depends on context / your requirements — specifically your acceptable notification latency, whether you can deploy and maintain a message queue layer, and your team’s familiarity with ION connection point configuration.

This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

We implemented webhooks for work order notifications and it’s been solid. The key is having a reliable queue system - when CloudSuite sends the webhook, we immediately queue it and return 200 OK. Then process asynchronously. If your endpoint is down, CloudSuite will retry up to 5 times with exponential backoff. Just make sure your webhook handler is idempotent since you might receive the same event multiple times.

4

Polling has advantages for simpler architectures. You control the timing and can implement backoff strategies during CloudSuite maintenance windows. With 150 concurrent work orders, polling every 5 minutes generates minimal load. The Maintenance API supports filtering by last_modified timestamp, so you only retrieve changed records. This approach also makes testing and debugging much easier since you control when requests occur.

5

How do webhooks handle authentication? Does CloudSuite sign the payload so we can verify it’s legitimate? Also concerned about firewall rules - polling only requires outbound connections while webhooks need inbound.

6

CloudSuite webhooks include an HMAC signature in the X-Infor-Signature header using a shared secret you configure. Always validate this signature before processing the payload. For firewall concerns, you can use a webhook relay service or expose your endpoint through an API gateway. Many organizations use AWS API Gateway or Azure Functions to receive webhooks, then forward to internal systems. This avoids opening direct inbound firewall rules.

7

Consider a hybrid approach for critical systems. Use webhooks as the primary mechanism for instant notifications, but implement a periodic polling fallback (every 30 minutes) to catch any missed events. This gives you the best of both worlds - event-driven responsiveness with polling as a safety net. We track webhook delivery success rates and automatically increase polling frequency if webhook reliability drops below 95%.

8

Both approaches have distinct advantages depending on your architecture and reliability requirements. Here’s a comprehensive analysis based on production experience:

Webhook Event-Driven Approach:

Webhooks provide true real-time notifications with minimal latency. When a work order status changes in CloudSuite, your mobile app receives an update within 1-2 seconds. This is ideal for time-sensitive operations like emergency maintenance or technician dispatching.

The event-driven model significantly reduces system load compared to polling. Instead of making 288 API calls per day (every 5 minutes), you only receive notifications when actual changes occur. With 150 active work orders, you might only get 20-40 webhook events daily for status changes.

CloudSuite’s webhook implementation in ICS 2022 includes robust retry logic:

  • Initial delivery attempt
  • Retry after 1 minute if failed
  • Retry after 5 minutes
  • Retry after 15 minutes
  • Retry after 1 hour
  • Final retry after 6 hours

If all retries fail, the event is logged in CloudSuite’s webhook delivery log for manual review. You can configure alert notifications for failed deliveries.

For reliability concerns, implement a message queue architecture. When your webhook endpoint receives an event, immediately acknowledge with HTTP 200 and queue the message for processing. This decouples webhook receipt from business logic execution. If your processing system is down, queued messages wait safely until it recovers.

Webhook authentication uses HMAC-SHA256 signatures. Validate every incoming request:

  1. Extract the X-Infor-Signature header
  2. Compute HMAC of the request body using your shared secret
  3. Compare computed signature with received signature
  4. Reject if they don’t match

Network considerations: Webhooks require an internet-accessible endpoint. Use an API gateway (AWS API Gateway, Azure API Management, or Kong) to handle inbound traffic securely without exposing internal systems directly.

Polling Increases Load Considerations:

Polling does generate more API traffic, but with proper implementation, the load is manageable. For 150 work orders, a well-designed polling strategy might look like:

  • Poll every 5 minutes during business hours (7 AM - 6 PM): 132 calls/day
  • Poll every 15 minutes during off-hours: 60 calls/day
  • Use last_modified_timestamp filter to retrieve only changed records
  • Implement conditional requests with ETag headers to avoid unnecessary data transfer

The Maintenance Management API supports efficient filtering:


GET /work-orders?last_modified_after=2025-05-02T09:00:00Z&status=in_progress,assigned

This returns only work orders modified since your last poll, minimizing payload size and processing time.

Polling advantages for your scenario:

  • Simpler architecture - no webhook endpoint management
  • Predictable load patterns - easier to plan CloudSuite capacity
  • No inbound firewall rules required
  • Easier local development and testing
  • You control polling frequency based on business needs

Reliability Varies - Practical Comparison:

Webhook reliability depends on:

  • Network stability between CloudSuite and your endpoint
  • Your endpoint’s availability (target 99.9% uptime)
  • Message queue reliability
  • Proper error handling and retry logic

Polling reliability depends on:

  • Your application’s ability to make outbound requests
  • CloudSuite API availability
  • Network connectivity from your side
  • Proper handling of API rate limits and timeouts

In practice, webhooks typically achieve 98-99% first-attempt delivery success. With retries, this increases to 99.5%+. Polling achieves similar reliability if you implement exponential backoff for API failures.

Recommendation for 150 Active Work Orders:

Start with polling for initial implementation simplicity. Use this configuration:

  • Poll every 3-5 minutes during peak hours
  • Filter by last_modified_timestamp
  • Implement exponential backoff for API errors
  • Cache work order data locally to detect changes
  • Log all API interactions for troubleshooting

Once your integration is stable and you’ve validated the data flow, evaluate whether webhook implementation would provide meaningful benefits. For 150 work orders with moderate status change frequency, polling is perfectly adequate and avoids the architectural complexity of webhook handling.

If you later need sub-minute notification latency (for emergency work orders or SLA tracking), implement webhooks specifically for high-priority events while maintaining polling for regular updates. This hybrid approach balances real-time responsiveness with operational simplicity.