Quick version: On the original (still-working) site: Settings → Security → Remote Unlock → Generate Remote Token, then copy the token and the Source URL. On the migrated site: Settings → Security → choose the Remote Unlock unlock method, enter the Source URL and token, and click Verify. The migrated site confirms itself against the original server over HTTPS and unlocks. The token lasts 30 minutes and works exactly once.
Remote Unlock is the Pro path out of an Environment Lock: instead of re-entering every credential or preparing a migration passphrase in advance, the migrated site proves to the original server that it’s yours.
New to APIs? Read this first
When your credentials use the Locked encryption tier, they’re sealed to one specific server — moving the site breaks the seal on purpose, so a stolen backup is useless to a thief. Remote Unlock is how the real new server proves it deserves a fresh seal. Background: Environment Lock explained.
Before you start
- Both sites must be reachable over HTTPS — the verification refuses plain HTTP.
- The original site must still be running with its credentials intact. If it’s already gone, Remote Unlock can’t help; use the migration passphrase (if you prepared one) or re-enter credentials.
- HuxxConnect Pro must be active on both sites.
Step 1 — Generate the token on the original site
On the site where credentials still work, go to Settings → Security → Remote Unlock and click Generate Remote Token.
Copy both values immediately — the interface warns: “Copy this token and the source URL — they will not be shown again!”
If a token already exists you’ll see “An active remote unlock token already exists.” with its remaining lifetime and a Regenerate anyway option. Regenerating invalidates the old token.
Step 2 — Verify on the migrated site
On the migrated site (showing the environment-mismatch notice), go to Settings → Security, pick the Remote Unlock method tile (“Verify against the source server to unlock remotely.”), enter the Source URL and the token, and click Verify.
The migrated site sends a challenge to the original server, which answers with an HMAC-signed response only it can produce. On success, your credentials are re-encrypted for the new environment and every API works again.
How the token behaves
| Property | Value |
|---|---|
| Lifetime | 30 minutes from generation |
| Uses | Exactly one — consumed on the first verification attempt, success or failure |
| Transport | HTTPS only; HMAC-SHA256 challenge–response, the token itself never travels in a URL |
| Retries | Rate-limited per IP and globally on the source server |
If it didn’t work
- “Failed to generate remote token.” on the source site — usually a REST problem on the source itself; check that
/wp-json/responds and no security plugin blocks the HuxxConnect routes. - Verification fails on the migrated site — the token was already used once (generate a fresh one), it expired (30 minutes), the Source URL doesn’t match the original site’s address exactly, or one of the sites isn’t serving HTTPS.
- Repeated failures then silence — you’ve hit the rate limit on the source server. Wait a few minutes, generate a fresh token, and try once, carefully.