Retry Domain Nexus requests without creating duplicate domain operations

Generate a unique reference when your application creates the business request. Store it with the local order and the exact method, route, query and raw JSON body. The key must be 1 to 191 printable non-space ASCII characters. Use a value that contains no credentials or customer identity data.

Send the same key only with the same request. A second renewal, a different registration period or a changed contact payload is a different business action and needs its own reviewed reference.

1. Submit the request once and record the HTTP status, request ID, operation ID and job ID returned.
2. For queued work, follow the operation or job through the documented read route.
3. If the HTTP connection times out, first check the existing operation and domain state. A timeout does not prove the provider rejected the action.
4. When a transport retry is appropriate, resend the unchanged request with its original idempotency key.
5. For HMAC, use a new nonce, timestamp and signature for that retry. Authentication freshness and business-request identity are separate.

IDEMPOTENCY_IN_PROGRESS means the request is already running or awaiting reconciliation; it was not executed again. IDEMPOTENCY_REVIEW_REQUIRED means a prior failure or uncertainty needs review. Changing the key to bypass either state can create another upstream request.

A completed stored response can be replayed, with replay information in metadata and refreshed operation context where supported. Sensitive one-time secrets are not a general-purpose replay store, so preserve a key when it is first revealed through its dedicated workflow.

Idempotency storage has a retention period. Your order system must retain its own completed-operation record and prevent a second charge or registrar request after that period. Do not depend on the API's temporary replay protection as the sole order ledger.

When a failed domain operation is eligible for the dedicated retry route, inspect the provider outcome first and retry that operation rather than creating a fresh registration or renewal. Some states require manual review.

After completion, compare the domain's status and expiry, the order settlement and the original customer request. This catches a workflow that returned valid JSON but did not finish the requested business action.

• Get started with the current Nabtech Domain Nexus v2 API
• Read Domain Nexus API errors and trace an uncertain request
• Synchronize a domain's current provider state through the v2 API
• Create a domain-operation quote and keep its currency and expiry attached to the order
• Offer domain suggestions without treating them as reservations