Name the three different questions
Was the request received? Did the operation finish? Does the intended result exist? These questions can have different answers at the same moment. Keep separate fields for submission, operation state and verification. That separation makes an unknown result visible instead of turning it into an optimistic completed label.
Follow the documented status route
HTTP 202 communicates acceptance without completion. Use the operation identifier, status endpoint or event mechanism defined by the actual provider to learn what happened next. The lifecycle example uses invented identifiers and responses to demonstrate the states; it does not reproduce a specific vendor contract.
MDN: HTTP 202 Accepted ↗ — Accepted means processing is not complete. The endpoint must define how its eventual result can be checked.
Define a bounded wait and a next owner
Use the service’s documented timing and rate-limit guidance. Establish a point at which the workflow stops waiting automatically and asks its assigned owner to inspect the record. Preserve the operation identity. A timeout is not proof that the remote side made no change, and starting a fresh create request can make reconciliation harder.
Verify the destination before closing the record
Inspect the approved revision and the intended page fields. If the operation says complete but the page is wrong, retain that discrepancy as a verification failure. A receipt should state what was checked, not merely repeat the submission status.
Record the plan, version, date, input set, output, failure behavior and billing units. A workflow diagram is a design pattern, not a benchmark.
