Emmanuel Evance
Context:
Our workflows often rely on the
SATUSEHAT API
, where triggering a workflow returns a
work order ID
. However, there is no API currently available to query the status of the work order, leaving us unable to programmatically check if a workflow has completed successfully or encountered an error.
This limitation is especially problematic in scenarios where:
  • Error handling requires delays
    : According to the SATUSEHAT API documentation, if a workflow fails, a
    rate limit policy of 1 request per minute
    is imposed for subsequent attempts. Without visibility into the work order status, this policy forces us to either retry blindly (risking repeated errors) or introduce arbitrary delays, which reduce efficiency and increase system latency.
Requested Feature:
Introduce an API endpoint to query the status of a workflow using the work order ID.
Proposed API Specification:
  • Endpoint:
    /api/workorders/{id}/status
  • Method:
    GET
  • Parameters:
-
id
(required): The unique ID of the work order.
  • Response:
{
"workOrderId": "12345",
"status": "In Progress", or "Completed", "Failed", "Pending", etc.
"details": "Optional additional information"
}
  • HTTP Response Codes:
-
200 OK
: Successfully retrieved the status of the work order.
-
404 Not Found
: The work order ID does not exist.
-
400 Bad Request
: Invalid work order ID format.
SATUSEHAT Rate Limiting Policy:
The SATUSEHAT API imposes a
rate limit of 1 request per minute
after a failed attempt. This policy is designed to manage system load and prevent repeated errors, but it adds significant overhead for systems without insight into work order statuses. Adding a status query endpoint would mitigate these challenges by allowing informed retries.
Additional Notes:
If an API for querying work order status already exists but is undocumented, providing documentation would also meet this need.