In short
A transfer hands items from your account to somebody else's permanently. You generate a code, share it out of band, and they enter it to accept. Nothing moves until they do.
The two things worth knowing before you start: links and Marks are selected as separate transfer types, though accepting a Mark carries its Dynamic Link across with it automatically; and once a transfer is accepted you cannot reverse it from your side — the new owner has to transfer back. You can cancel a transfer while it is still outstanding, but not after the code has been redeemed.
On this page
How a transfer works
Transfers use a code rather than an email invitation, and that choice shapes everything about them. You are not sending anything to an address — you are minting a claim ticket and deciding who to hand it to.
Links and Marks move separately
Transfers come in two kinds and they are not interchangeable. A code generated for links will not carry Marks, and a code generated for Marks will not carry standalone links.
| Kind | Moves | Note |
|---|---|---|
| Link transfer | Dynamic Links you own | For short addresses with no artwork behind them |
| Mark transfer | Linxy Marks, and the Dynamic Link behind each one | The link travels with the Mark automatically — you do not transfer it separately |
Handing over a whole client engagement therefore usually means two transfers and two codes. Send them together with a note saying which is which, or you will spend an afternoon on "the code doesn't work".
Sending a transfer
- Select the items.Pick the Marks or the links you intend to hand over. Only items you still own can be included; anything already transferred away is skipped silently.
- Generate the code.You get a short uppercase code. It appears in your transfer history as pending.
- Share it out of band.The platform does not deliver it for you. Email, message, or say it out loud — but treat it as a credential, because it is one.
- Wait.Until the code is redeemed, the items are still yours, still resolving, still tracked. There is no half-transferred state.
Accepting one
- Sign in to the account that should own the items.This is the decision that cannot easily be undone. Get it right before entering anything.
- Enter the code.In the transfers area of the console.
- Choose a client and project.You are offered your own client and project at this point. Use it — incoming items arrive with the previous owner's assignment cleared, so if you skip this they land unassigned.
- Confirm.Ownership moves. The items now appear in your lists and behave as though you had made them.
Transferring one Mark by its own code
Every Mark also carries its own individual transfer code, shown in the Mark’s editor, under Transfer on the Mark’s sheet in My Linxy in the Linxy App, and returned by the API as its transfer code. Entering that code has the same effect as accepting a one-item transfer.
This is the convenient route for handing over a single object — a client asking for the one Mark on their packaging, say — without building a transfer batch for it. The trade-off is that the code exists whether or not you have decided to transfer anything, so treat it with the same care as any other credential attached to that item.
Canceling
A pending transfer can be canceled from your transfer history, which invalidates the code. Do this the moment a code goes to the wrong person or a deal falls through.
After acceptance there is nothing to cancel. The items belong to somebody else, and getting them back requires them to transfer to you — which means they have to agree, and they have to still have them.
What changes for the new owner
| What happens | |
|---|---|
| The printed artwork | Unaffected. Every copy in the field keeps working throughout — nobody scanning notices a transfer happened |
| The short address | Unchanged. It resolves exactly as before |
| Settings | Carried over intact — destination, routing, protection, expiry |
| Interaction history | Goes with the item. The new owner sees the accumulated data |
| Client and project | Cleared. Your organization does not follow the item; the recipient assigns their own at acceptance |
| Your access | Gone. The items leave your lists and you can no longer edit, view stats, or transfer them |
The artwork row is the reason transfers exist. Ownership of a touchpoint can change hands — agency to client, department to department, on sale of a product line — without a single printed object being reprinted or a single address breaking.
When to transfer, and when not to
| Situation | Transfer? |
|---|---|
| Handing finished work to the client who commissioned it | Yes. This is the intended case |
| Ending an agency relationship | Yes — and do it before the final invoice, not after |
| Moving items between two accounts you own | Yes, and easier than recreating anything |
| Letting a colleague help manage items | No. That is collaboration, not ownership — transferring removes your own access |
| Giving somebody a look at the numbers | No. Export the data instead |
| Not sure whether the deal will complete | Not yet. Generate the code when you are ready to lose access |
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| The code is rejected | Wrong kind of transfer, mistyped, or already canceled | Confirm whether it is a link or a Mark transfer; codes are uppercase |
| Code accepted but nothing arrived | The sender no longer owned the items, so nothing moved — and the code stays usable | Sender checks they still own them, then reissues |
| Fewer items arrived than expected | Some had already been transferred elsewhere and were skipped | Sender generates a second transfer for the remainder |
| Items arrived unassigned | Client and project were not chosen at acceptance, and the previous owner's assignment is cleared by design | Assign them now; choose at acceptance next time |
| Redeemed on the wrong account | Signed in as the wrong identity when entering the code | The receiving account must transfer them onward — the sender cannot pull them back |
| Want a transfer undone | It was accepted | Only the new owner can transfer them back |
| Scans stopped working after a transfer | Not caused by the transfer — check whether the new owner changed or deactivated something | Ask the new owner; artwork and addresses survive transfers untouched |
Things people commonly get wrong
Related reading: Projects, clients and templates, Mark settings, Reading your interaction data, and Batches and bulk creation.