1. Store the returned operation public ID, request reference, local order reference and idempotency key when submitting work.
2. Read the operation resource. If locating older work, list operations for the owned domain.
3. Compare the stored state with provider evidence and the domain's reconciled status. A complete internal worker timeline is not guaranteed in the operation response.
4. For a failed or manual-review result, identify whether the provider rejected the action, accepted it with a lost response, or still has it pending.
5. Use the supported retry operation only when the existing state permits it and the provider outcome has been reviewed.
6. Re-read the final domain and relevant settlement before reporting completion.

When the original submission returned an operation reference, use the server-side PHP request helper in the API getting-started article to inspect that operation before attempting another paid action. Run the request in the same authorised reseller context with domains:read access.

$operationId = 'OPERATION_ID';
$result = nabtechRequest('GET', '/v2/operations/' . rawurlencode($operationId));
if ($result['http_status'] !== 200 ||
    !is_array($result['response']['data'] ?? null)) {
    throw new RuntimeException('Operation requires further investigation.');
}
$operation = $result['response']['data'];
// Reconcile the documented state with the original order and provider outcome.

Read the result: An HTTP 200 means the operation record was retrieved. It does not mean the original registration, renewal or transfer completed. Preserve pending and manual-review states in the customer workflow and verify the relevant domain and settlement before reporting success.

If the reference cannot be read, retain the original request details for support. Do not generate a fresh idempotency key simply to make an uncertain order start again. A supported operation retry is a separate reviewed recovery action.

The current retry workflow accepts specified recoverable states, including failed, manual-review and compensated operations. Eligibility is a guard, not a promise that blindly repeating the action is safe. A provider-side success with a missing local update needs reconciliation, while a corrected validation error may need a reviewed retry.

Submitting a fresh paid operation to bypass an uncertain one can duplicate work or obscure settlement evidence. An identical transport retry uses the original idempotency key and body. An explicit operation retry is a separate recovery action with its own required idempotency handling.

Show pending, completed or action-needed according to the verified outcome, with a stable order reference. Avoid exposing internal provider secrets or promising completion from a local queue acceptance. If the result needs support review, supply the operation and request references so the original attempt can be traced accurately.

• Read Domain Nexus API errors and trace an uncertain request
• Retry Domain Nexus requests without creating duplicate domain operations
• Track domain orders and cancel only work that remains cancellable
• Synchronize a domain's current provider state through the v2 API