In short
If you have put LinxyPass on your site, you run the door. You decide how people get in — by asking you first, or by scanning your Mark — you approve or decline requests, and you choose when the site opens to members at all. All of it lives on your partner dashboard, along with your sign-in Mark, how it looks on your page, and your credentials. Setting a site up in the first place is covered in Adding LinxyPass to your site.
The responsibility this creates is easy to underestimate. With enrollment locked — the recommended setting, and where a new site starts once your own phone is its owner key — nobody gets in until a person approves them, so an unwatched queue is a locked door with nobody behind it. The most common failure of a LinxyPass deployment is not technical at all. It is a request queue that nobody is looking at.
On this page
- Getting to your dashboard
- Going live, and taking the site offline
- How new members get in
- The request queue
- What you can do with a request
- The enrollment email you send
- People already enrolled
- Your sign-in Mark
- Sign-in mode, credentials and the rest
- How you find out about requests
- Symptoms, causes and fixes
- Things people commonly get wrong
Getting to your dashboard
Your dashboard lives at lnxy.me/partner/dashboard. A LinxyPass site belongs to the Linxy account that set it up, so the ordinary way in is to be signed in to lnxy.me with that account. The last step of setup also offers Go to my dashboard.
Dashboard links generated for you are short-lived by design: about five minutes. They are meant to be used the moment they are created, not saved or shared. If one has stopped working, generate a fresh one or simply sign in to lnxy.me with the owning account.
Going live, and taking the site offline
Until your site is live, LinxyPass works for you and nobody else; everyone else is refused and every refusal is recorded. The top of the dashboard shows the checklist — prove you control your domain, add LinxyPass to your site, try it yourself — and then the switch that lets anyone but you through: Go live. Once it is on, the panel reads Your members can sign in.
Take offline returns the site to owner-only. Members keep their enrollment and their Connection card; they are simply refused until you switch it back. Nothing is deleted. Moving LinxyPass to a different domain also returns the site to owner-only until the new domain is proven — your Mark, members and settings are untouched.
How new members get in
The Enrollment Security section holds one switch, Allow scan-path enrollment without approval, and it decides what happens when somebody new scans your Mark.
| Setting | What a newcomer who scans your Mark gets | Good for |
|---|---|---|
| Locked (recommended) | A Request Access prompt. They are enrolled only after you approve them, or after you invited them | Business accounts, member sites, anything private |
| Open | Enrolled straight away after they confirm with face or fingerprint on their phone | Low-security, public scenarios only |
When your own phone becomes the site’s owner key during setup, the switch is set to locked. Open it only deliberately; the dashboard asks you to confirm before it does. Whichever setting you choose, the site has to be live before anyone but you gets through, and every newcomer still confirms on their own phone.
The request queue
Every person who asks for access appears under Access Requests as pending, with filters for All, Pending, Approved, Denied and Enrolled. A request carries the name and email they gave, and technical details captured at the time — the address it came from and the browser used — which are occasionally useful for spotting something odd.
Requests do not time out, expire or escalate. They wait indefinitely. That is safe but it is not self-managing. And a request made through the form is always created pending — the switch above changes what a scan does, not what a request does.
What you can do with a request
| Action | What it does | Reversible? |
|---|---|---|
| Approve | Marks the request approved and sends an enrollment email with a link | Yes — you can revoke afterwards |
| Deny | Declines the request, with a reason you can record | Yes — Re-approve it, and the person can also ask again |
| Resend Email | Sends the enrollment email again for an approved request | — |
| Revoke | Ends access for somebody who was approved or already enrolled | They would need to request access again |
| Clear | Removes the request record entirely | No — though the person can submit a new request later |
Two of these deserve a closer look.
Denying is not a block. A declined person can submit a fresh request, which returns to your queue as pending with the earlier denial cleared. If you need somebody kept out permanently, denying repeatedly is not the mechanism — deal with it directly.
Approving somebody who already has access is caught before anything is sent. If a binding already exists for that email, the request is marked as enrolled and you are told, rather than a second enrollment email going out.
The enrollment email you send
Approval generates a single-use enrollment link and emails it to the address on the request. It is valid for seven days.
Two consequences worth planning around. Approving somebody who is on holiday may mean the link lapses before they see it — Resend Email is there for an approved request that has not been used. And because the link binds to whoever is signed in to the Linxy App when it is opened, forwarding it does not transfer access; it either enrolls the wrong person or fails outright.
If somebody says their link expired, approve a fresh request when they are ready to act on it, rather than hoping an old approval still holds.
People already enrolled
Separately from the queue, you can see everybody currently enrolled with your site and remove any of them. Removing somebody ends their access; they would have to enroll again to return. The one phone you cannot remove there is your own as the site’s owner: you are told That is the site owner’s phone. It can’t be removed from Members. — removing it would lock you out of your own site.
Remember what a person’s enrollment actually is: a binding between one of their devices and your site. Somebody who enrolled a phone and a tablet holds two.
Your sign-in Mark
Your sign-in page displays a Linxy Mark. Under Your LinxyPass Marks you can upload Marks, choose which one is live with Set as Live, and delete ones you are not using. Exactly one Mark is live at a time, and your site needs one for enrollment to work at all — without it, people finishing their enrollment are told the site has no Mark configured, which looks to them like a fault on your end because it is one.
Sizes. Every Mark is made in card sizes of 560, 480 and 420 pixels, all carrying the same Mark, so members’ phones read any of them; an image of 1920 × 1200 or larger also makes a Full page size. Your page picks the largest size that fits the space it is placed in. Make missing sizes fills any gap.
How it is shown. Under Your sign-in page you choose Full page, Card or natural size and press Save display; it takes effect without touching your site’s code. On WordPress the plugin’s own Login display setting decides this instead.
Branding. Brand your sign-in image places your logo or a message on top of your Mark. The result is scanned before it is saved, so branding can never stop your Mark from reading, and Apply branding to all sizes carries it to every size. Branding shows on computers only; phones see the plain Mark. On the full-page sign-in a computer draws your logo live over the Mark, so it stays sharp at any screen size — upload it as SVG for the crispest result (an SVG that cannot be used safely is replaced by a PNG copy). Remove branding and Restore earlier branding undo it.
Check that a Mark is live before you announce LinxyPass to anybody. The failure is silent from your side and visible from theirs.
The card your members see in the Linxy App is a different asset with its own page; see Branding your Connection card.
Sign-in mode, credentials and the rest
| Section | What it does |
|---|---|
| Sign-in mode | Standard: members approve with a tap on their phone or a paired watch. LinxyPass Verified: a live face or fingerprint every time, and tap and watch approval stop working for your site. Changes take effect immediately |
| Add LinxyPass to your site | Your Partner ID, Download the plugin for WordPress, Download the PHP kit, Request setup help for other platforms, and Try it, which opens your real sign-in on a page Linxy hosts for fifteen minutes so you can scan it before your own page is ready |
| Credentials | Issue a new key replaces your API key; the old one stops working immediately. Members are not affected — sign-in, enrollment and open sessions do not use it — but your WordPress plugin or integration stops talking to Linxy until you paste the new key in. The key is shown once. A webhook signing secret, if you use a webhook, can be revealed again or replaced |
How you find out about requests
When a request is submitted, your site can be notified straight away so it can alert you — on WordPress, the plugin turns this into an email to the site administrator.
That notification is deliberately best-effort. If it fails for any reason, the failure is recorded but the request itself is never blocked. This is the right trade — a broken notification must not stop somebody asking for access — but it has a consequence you should plan for: your alerts are not a reliable inventory of what is waiting. Check the dashboard on a schedule rather than relying on being told.
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| Members are refused, and nobody but me can sign in | The site is not live | Finish the checklist and press Go live |
| People say they requested access and heard nothing | The queue has not been worked | Open Access Requests. A request never approves itself |
| People who scan the Mark are asked to request access | Enrollment is locked | Approve their requests, or open scan enrollment if your site is genuinely public |
| I get no notification emails | The notification is best-effort and can fail silently | Check the dashboard regularly regardless |
| Someone’s link expired | More than seven days since approval | Approve a fresh request when they are ready |
| “Already enrolled via another path” | A binding for that email already exists | Nothing. The record has been corrected for you |
| People report the site has no Mark | No live Mark is set | Upload one and set it live |
| My plugin stopped connecting right after I replaced the key | The old API key stops immediately | Paste the new key into the plugin or your integration |
| “That is the site owner’s phone. It can’t be removed from Members.” | You tried to remove your own owner phone | Nothing. It stays so you are never locked out |
| My dashboard link stopped working | These expire in about five minutes | Generate a new one, or sign in to lnxy.me with the owning account |
| Someone I denied keeps reappearing | Denial is not a block; they can re-request | Contact them directly |
| Removing someone did not stop all their devices | Each device holds its own binding | Remove each binding for that person |
Things people commonly get wrong
Related reading: Adding LinxyPass to your site, Enrolling a site, Branding your Connection card, and Signing in with LinxyPass.