> ## Documentation Index > Fetch the complete documentation index at: https://docs.utmkit.co/llms.txt > Use this file to discover all available pages before exploring further. # Edit and withdraw a link > What can change on a link after it is created, what never changes and why, and what happens to visitors when a link is withdrawn. A link can be corrected after it exists — but not everything about it can move, because copies of its address are already out in the world. ## From the console On [https://app.utmkit.co/links](https://app.utmkit.co/links), **Edit** opens the editor for one link and **Delete** withdraws it. Owners, admins and members can do both; viewers cannot. ### What can change * **The destination.** A new destination goes through the same safety check as a new link before it is saved. * **The iOS and Android destinations.** Add, change or clear them — see [deep links](/en/links/deep-links). * **The UTM parameters.** A parameter locked for your seat is offered as a choice of approved values instead of a free text box. * **The expiry date** — see [expiry dates](/en/links/expiry). * **The note and the tags** — see [tags and saved views](/en/links/tags-and-saved-views). * **The campaign.** Tick one or more links in the list and use the **Campaign** menu. This changes where the link is grouped and nothing else: its own `utm_campaign` stays as it is, so clicks already counted under that value stay where they are. ### What never changes: the short code and the domain The editor says it plainly: *the short code and the domain stay as they are; everything already shared keeps working.* Together they are the address printed on your posters and pasted into your emails, and moving either would break every copy already handed out. There is no disabled field for them, because the answer is not "not now" but "not ever". For a different address, create a new link. ### Every edit is checked again An edit is validated against the workspace's [convention](/en/rules/the-convention) like a new link, and refused if it would make the link a duplicate — the same destination and the same five UTM values as one the workspace already has; the refusal names that link. The edge copy is then updated on the path a new link takes, and the row reads **Not live yet** until confirmed. ### Withdrawing a link **Delete** asks you to confirm — *it stops resolving for everyone who has it* — then removes the link from the edge and from your list, its click totals with it. Anything already printed with that code stops working the moment you confirm, and it cannot be undone: a withdrawn link is created again, not restored. A visitor who opens the old address afterwards is sent nowhere. On the shared domain they see UTMKit's own page; on your own domain, a plain "Not found". ### When UTMKit withdraws a link for you Destinations that already have links are re-checked daily, as many as each day allows. If one becomes listed as malware or phishing, its link is taken off the edge without waiting for you. It stays in your list with a **Withdrawn** badge and the reason under it — *Withdrawn: that destination is listed as … and cannot be shortened* — so you know what happened and which destination to dispute. ## From the API and the MCP `PATCH /api/v1/links/{id}` edits a link and `DELETE /api/v1/links/{id}` withdraws it; the MCP tools are `update_link` and `withdraw_link`. All four require `links:write`. A `PATCH` carries only the fields that change, and a body naming `short_code` or `domain` is refused in the console's own words rather than silently ignored; the iOS and Android destinations are edited through the API operation, not the MCP tool. The reference owns the fields.