In short
The console mints NFC tokens: long random identifiers, one per tag, which you then write onto physical tags with the App or, at production pace, the desktop Linxy NFC Encoder. Each token can be labeled, pointed at its own destination, given its own parameters, and revoked.
The detail that explains everything else on this page: a Linxy NFC tag does not contain your destination. It contains an opaque token that only the platform can resolve — which is exactly why a tag can be switched off after it has been stuck to something.
On this page
What is actually on the tag
Most NFC tags you have met contain a URL. Tap one with any modern phone and the operating system offers to open it, because a URL record is a standard every phone understands.
Linxy tags are deliberately not that. A tag written by the Linxy App or the Linxy NFC Encoder carries a 32-character random token in three records: a lnxy.me link built from the token, the same token in a Linxy record the App reads directly, and an Android app record so a tap opens the Linxy App without offering a browser. None of them contains your destination.
Two consequences follow, and both are worth stating plainly. The tag shows nothing to a passer-by without the App — their phone follows the link to a Protected Content page that says the content can only be viewed in the Linxy App and offers to get it. That is a feature, not a limitation, and it is the wrong technology if you want anyone with any phone to tap it. And every tap is a question asked of the platform, which is why destinations can change and tokens can be turned off after the tag is physically inaccessible.
Generating tokens
Tokens belong to a Mark. You open the Mark, go to its NFC area, and generate as many as you need — each one a fresh 32-character random identifier that has never existed before.
| Input | Behavior |
|---|---|
| How many | Up to 50 in one go. Ask for more and you are quietly given 50 — no error, so check the count you got rather than the count you typed |
| Label | Optional, and for your eyes only. Generate several at once with a label and each gets the label plus a number, which is how you keep a run identifiable |
Label them properly at generation. Fifty unlabeled 32-character tokens are indistinguishable from one another in a list, and matching a physical tag back to its record afterwards means tapping tags one at a time to find out which is which.
Per-tag destinations and parameters
By default every token resolves through its Mark, which means all tags on one Mark behave identically. Two optional per-token fields break that, and they are what make NFC worth using over a single Mark with many copies.
- A per-tag destination. Set an address on an individual token and that tag goes there instead of following the Mark. One Mark, one design, fifty tags, fifty different destinations if you want them.
- Per-tag parameters. Named values stored on the token and substituted into the outgoing address wherever you have placed a matching placeholder. This is how a tag identifies itself to the page it opens — table number, room, asset ID, seat, shelf position.
The parameter mechanism is the more useful of the two, because it lets one destination serve every tag while still knowing which tag was tapped. Point every token at the same page, give each one a parameter with its own value, and the page receives that value on arrival.
Getting tokens onto tags
Generating a token creates a record. It does not put anything on a physical tag — that is a separate physical step, done with hardware that can write NFC.
- Generate and label the tokensin the console, in the quantity you actually need.
- Write each token to its tagusing the Linxy App on a phone with NFC, or the desktop Linxy NFC Encoder with a USB reader-writer for a production run. The tool writes the proprietary record for you — you do not construct it by hand.
- Verify by tappingbefore the tag goes anywhere permanent. Confirm it resolves, and confirm it resolves to the right thing if you set per-tag destinations.
- Record which tag went wherewhile you still can. Once tags are on shelves, doors or assets, the labels in the console are the only map you have.
Revoking
Revoking a token switches it off. The tag is physically unchanged and still contains the token, but the platform stops honoring it, so tapping it produces nothing useful.
This is the payoff for the opaque payload, and the situations it covers are the ones that actually happen: a tag lost with an asset, a batch written incorrectly, a returned demo unit, an employee badge that should stop working today, a tag someone has copied. None of that is recoverable with a URL tag.
Revoke rather than delete when you want the record kept for audit. Revocation is per token, so one bad tag out of fifty costs you one tag.
The web fallback page
The link written on each tag is also that token’s web page on the platform. With the Linxy App installed, the App opens it and resolves the token. Without the App, it shows the Protected Content page, with Get the Linxy App and store buttons, and never the content itself.
It is a supplement, not the primary path. Opening the content always needs the App. Remember that the link is an ordinary shareable address: anyone who has it reaches the same page a tap would, and the same App check applies.
Large runs by CSV
For volume, tokens can be imported from a CSV rather than generated one at a time — up to 500 rows per import, each row becoming one tag with its own label, destination and parameters. Every column you map as a parameter is stored on the token, and you can map as many as you need.
This is the right route for anything at asset-register scale: a spreadsheet you already maintain becomes the source of truth, and the tokens inherit its structure. Keep the CSV afterwards — it is the map between physical tags and console records, and it is much easier to keep than to reconstruct.
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| Tapping the tag opens a Protected Content page | The phone does not have the Linxy App, so it follows the tag’s link to a page that asks for it | Working as designed. Install the App, or use a different touchpoint type if any phone must work |
| Generated fewer tokens than requested | The request was clamped to 50 without an error | Generate in batches of 50, or import by CSV for larger runs |
| Cannot tell which tag is which | Tokens generated without labels | Label at generation. For existing tags, tap each one to identify it, then rename |
| All tags go to the same place | No per-tag destination set, so each follows its Mark | Expected. Set per-tag destinations, or use parameters if the destination is shared |
| The destination page does not receive the tag's value | Parameter stored but no matching placeholder in the address | Add the placeholder to the destination so the value can be substituted in |
| A revoked tag still seems to work | Revocation applies per token — a nearby tag may carry a different one | Tap it and check which token responds, then revoke that one |
| The NFC area is not visible | Plan entitlement | Check the plan; this shares an entitlement with Events |
| A written tag will not read at all | Failed or partial write, or an incompatible tag | Rewrite and re-verify. Test one tag from each new batch of blanks before committing to a run |
Things people commonly get wrong
Related reading: Types of Linxy touchpoint, and how to choose, Mark settings, Secure NFC versus standard NFC, and Batches and bulk creation.