ResolveAlerts resolves alerts **this integration raised**, recording why.
You call thissales:orders:fulfillment:self
const url = 'https://api.zentail.com/v2/shipping/fulfillment_orders/alerts/resolve';const options = { method: 'POST', headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'}, body: '{"resolutions":[{"fulfillmentOrderId":"example","type":"ALERT_TYPE_UNSPECIFIED","resolution":"example"}]}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request POST \ --url https://api.zentail.com/v2/shipping/fulfillment_orders/alerts/resolve \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '{ "resolutions": [ { "fulfillmentOrderId": "example", "type": "ALERT_TYPE_UNSPECIFIED", "resolution": "example" } ] }'Scoping matters: an alert of the same type raised by Zentail itself, or by another integration, on the same order survives. Resolving by type alone would let one caller silently clear another’s alerts.
Authorizations
Section titled “Authorizations”Request Bodyrequired
Section titled “Request Bodyrequired”object
One entry per alert to clear. Required and server-capped. Only alerts this integration raised are in scope — naming one raised by Zentail or by another integration clears nothing.
object
The fulfillment order carrying the alert.
AlertType maps to Zentail’s customer-order alert types. Only the types a fulfillment integration can legitimately raise are exposed.
- ALERT_TYPE_UNSPECIFIED: Refused. Every alert names a type.
- ALERT_TYPE_FULFILL: Something is blocking fulfilment but you have not given up on it. If you have, reject instead.
- ALERT_TYPE_LATE_SHIPMENT: Will miss, or has missed, the ship-by deadline.
- ALERT_TYPE_LOST: Shipped but the package is lost in transit.
- ALERT_TYPE_OTHER: Anything else worth telling a user about. Put the specifics in
message— it is the only thing that reaches a person.
Why it is resolved. Stored alongside the alert and shown to the user.
Responses
Section titled “ Responses ”A successful response.
object
One result per resolution sent, keyed by fulfillment order and type. Read already_resolved before reacting: nothing open to clear is the normal answer to a retry, and to a user having cleared it first.
AlertResolveResult mirrors AlertResult but carries the resolve path’s own soft-success flag. AlertResult’s already_open only makes sense when raising; on a retried resolve it would be nonsense, leaving a caller that timed out and retried with no honest way to read success.
object
The fulfillment order the alert was on, echoed back.
AlertType maps to Zentail’s customer-order alert types. Only the types a fulfillment integration can legitimately raise are exposed.
- ALERT_TYPE_UNSPECIFIED: Refused. Every alert names a type.
- ALERT_TYPE_FULFILL: Something is blocking fulfilment but you have not given up on it. If you have, reject instead.
- ALERT_TYPE_LATE_SHIPMENT: Will miss, or has missed, the ship-by deadline.
- ALERT_TYPE_LOST: Shipped but the package is lost in transit.
- ALERT_TYPE_OTHER: Anything else worth telling a user about. Put the specifics in
message— it is the only thing that reaches a person.
True when no alert of this type is open any more, whether this call closed it or found nothing to close. False is a real failure.
Why it failed, in prose, for logs and support. Empty on success.
True when no open alert of this type remained, so nothing changed. Treat as success: it is what a retry after a timeout sees, and what a poller sees when a user resolved the alert by hand first.
Example
{ "results": [ { "type": "ALERT_TYPE_UNSPECIFIED" } ]}default
Section titled “default”An unexpected error response.
object
object
Examplegenerated
{ "code": 1, "message": "example", "details": [ { "@type": "example" } ]}