Skip to main content
POST
Recheck Registration Readiness
Send an empty JSON object {} using the account’s authorized API key after saving the current request. Do not send a client verdict, review content, packet, or account ID. Check the latest canRecheck permission before requesting a check. Use a stable Idempotency-Key to retry the same check request. Read the GET endpoint for its current result; replaying a POST can return its original queued acknowledgement. Use a new operation key for a new check after corrections. Sandbox keys cannot queue reviews. The 202 response contains the same readiness object as Get Registration Readiness. A queued or processing state acknowledges asynchronous work; it is not a passing review. Read that same endpoint until the review reaches a terminal state. Avoid repeated POSTs while a check is in progress. Findings describe concrete corrections and uncertainty. In shadow mode they are advisory; enforcement decisions come from the server’s blocking value. Rechecking does not verify a business, publish a preview, buy a number, or approve a registration. Preserve the saved request ID across corrections, timeouts, and 409 conflicts. Read the request after an uncertain outcome, and follow its current permissions before retrying. For request creation and updates, retain the operation’s original idempotency key and exact payload for an exact replay; do not use readiness failure to create a replacement registration. Agent-prepared drafts return 409 agent_review_required from this POST. Recheck them in the Trackly owner review, which carries the current revision, preview digest, and browser CSRF proof. An ordinary PATCH or a readiness request cannot expand delegated registration permissions or edit a frozen published snapshot.