Keep a fulfillment cancellation request pending until answered

A request is not a confirmed work result

In the original F1 example, an external service already accepted fulfillment work. Request C1 asks it to cancel. This local contract treats an accepted cancellation answer as cancelled work, a rejected answer as active work and no answer as unknown work state. It presumes answer identity has already been matched to C1; event authentication/order/replay is outside the model.

Preserve the actual external answer

The baseline has no answer, so C1 is pending and the current work state is unknown. “Request sent” is not proof that goods were intercepted, recovered or refunded. Accepted and rejected answers are separate alternative cases, not consecutive events that both happened.

1. Retain fulfillment and request IDs
2. Await the matched answer
3. Record accepted or rejected result
4. Keep unresolved work visible

Do not repeat a live cancellation request because a local status page was refreshed.

Define the handoff evidence before integrating

The complete material contains pending, accepted and rejected alternatives. A custom integration must establish matched references and authoritative current state; use the existing order-cancellation owner for internal work disposition.

Only accepted, rejected or null answers are accepted, with nonempty fulfillment/request IDs. Match the answer to the request before entering this model; it does not validate that identity. Unsupported answer values or malformed IDs are rejected, not turned into a stopped shipment. This page sends no request, buys no label, issues no refund and decides no cancellation rights.

The local timeline can supply a clear integration requirement without claiming the external service will always be able to stop work.