Change webhook URL
Point Token Vault at a different webhook without deleting your vault.
Use this when you're moving your webhook — a new deployment, a new host, a new domain — and want Token Vault to start routing to it, without deleting and re-creating your whole vault.
When to use it
- You redeployed your webhook at a new URL (new Cloudflare Worker, new tunnel domain, new server).
- You're migrating from one self-hosted setup to another.
You don't need this for an in-place upgrade at the same URL — that's just a normal redeploy; see Updating your webhook.
Requirements
Changing the webhook URL needs:
- An unlocked vault. If access is stopped, resume it first.
- A recent sign-in (within the last 5 minutes) — same reauth rule as unlocking or deleting the vault.
Where it is
Settings → Vault → Webhook (/settings?section=webhook) has a Change webhook URL card below the webhook health check. Click it, confirm the dialog, and you're dropped back into the guided bind flow in "re-bind" mode — the same wizard as first setup, pointed at your new URL.
What happens
- You enter the new webhook's URL and Token Vault runs the same bind handshake as a first-time setup.
- Token Vault refuses to complete the bind if the currently-bound URL changed underneath you — the confirmation dialog snapshots the URL it saw when you opened it, and the bind step compares that against what's live. If someone else has already changed it, you get a
409 WEBHOOK_CHANGEDand have to reload and retry. - Once bound, every MCP OAuth session on the account is revoked — the old sessions were minted trusting the old webhook binding, and can't be allowed to silently keep working against the new one. Connected MCP clients (Claude, Cursor, etc.) will need to sign in again on their next call.
Credentials don't move with you
Your credentials live on your webhook, not on Token Vault — Token Vault never holds them and has no way to copy them anywhere. Rebinding to a new webhook does not migrate any stored token from the old one. If the new webhook is a genuinely separate deployment (not just a redeploy of the same instance), re-add your credentials on the new webhook before you rely on it — nothing carries over automatically.