How to GET Visitor ID in Wix

It’s not possible to get member id if member is not logged-in yet. Which make sense but some applications are “visitor ready” and can be used without any account.

But as I said it’s not possible to get a member id/visitor id with any API in Wix. But there is a way to create a custom API that will work with Wix’s system to get user’s visitor ids that’s actually generated by Wix and used in Wix Apps!

How?

Few days ago I found something while working with “http-functions” (your own custom REST APIs). Let me show you;

In http-functions we have a parameter in functions which is req this parameter contains info about the request that made to our API.

More about req parameter

And inside of that req parameter we have a property called headers which contains request headers. And we can actually access visitor id from this headers prop that’s located in req.

Quick test:

Go to your http-functions.js file and add this code:

import { ok, response } from 'wix-http-functions';

export async function get_currentVisitorId(req) {
    try {
        return ok({
            body: JSON.parse(req.headers.identities)
        });
    } catch (err) {
        throw Error(`Failed to get current visitor id: ${err}`);
    }
}

This code will return something like this:

{
    "identificationData": {
        "context": {
            "metasiteId": "ff4848ad-7003-4d29-8549-67e943acf832",
            "visitorId": "1edde3e1-c4ec-45ab-8986-ba3c40148e5d"
        },
        "identities": [
            {
                "person": {
                    "type": "VISITOR",
                    "id": "1edde3e1-c4ec-45ab-8986-ba3c40148e5d"
                }
            }
        ]
    },
    "signedToken": "IDN2.eyJraWQiOiJwXzhJbHFzLSIsImFsZyI6IlJTMjU2In0.eyJkYXRhIjoie1wiY29udGV4dFwiOntcIm1ldGFzaXRlSWRcIjpcImZmNDg0OGFkLTcwMDMtNGQyOS04NTQ5LTY3ZTk0M2FjZjgzMlwiLFwidmlzaXRvcklkXCI6XCIxZWRkZTNlMS1jNGVjLTQ1YWItODk4Ni1iYTNjNDAxNDhlNWRcIn0sXCJpZGVudGl0aWVzXCI6W3tcInBlcnNvblwiOntcInR5cGVcIjpcIlZJU0lUT1JcIixcImlkXCI6XCIxZWRkZTNlMS1jNGVjLTQ1YWItODk4Ni1iYTNjNDAxNDhlNWRcIn19XX0iLCJpYXQiOjE3MTE0MDM0MDksImV4cCI6MTcxMzk5NTQwOX0.EvUHh_LnPbeK9tLjEL50BgvocRD7_xmTXLUcM5Ykw-NfE55KjOI-gYa_iQQ72JawaBVuEa-HJH7a--T2bvoVvTxVRhPgo9l0y82xTdB8kFcM_qQQI2IMALHk5LkYa_m0lFSLm58OSqp7uiWhNO3bhB0KHFgHaCPnVXdk3oxW_Ph4d1I-5-Yw2dhM0o3XktoJn8DxYrBttv7zsBb82ip_n0I_8D1wmPE_bmUY8TTuOkmikAYlGKatB9jMK2itgg0JmSrA19DAN21yA83hGZmg7gHYCLifgO-BZ67t21cW7CelZA90hfEIUmuItEX0IeRTDfMAz51ZPP6FCRabcR-rgg"
}

Boom! We got the current visitor id or if user is logged in you can also get the current member id from this API response.

Demo here (will be unpublished after few days)

You can get much more info from headers, using same system.

How to Use This API?

After that point when you setup the API all you need to do is call this API from the frontend and save the returned data to localStorage/sessionStorage if needed.

You can use axios or Wix’s fetch APIs for calling the API or native fetch function in JS

Example:

// IN PAGE CODE or ANY FRONTEND FILE

const res = await axios.get("your api url");

I will also build an NPM package that you can setup with single line for this that also includes visitor id and other details.

5 Likes

Nice work!!! Very useful!!!

1 Like

Thanks! It’s actually very useful but we can’t use this in backend directly so it would be really cool if we would have a Velo API for this. But I’m also not sure if it’s even possible (logically) to get a visitor id in backend directly.

1 Like

Wow, that’s a brilliant method!
Thanks for sharing it with the community, @LoeiX!

Yes, that’d be really helpful. I hope Wix adds a Velo API for this.

1 Like

Is this something that we would have to disclose in a cookie policy for compliance?

Will this still work if user declines cookies? Or if user clears cache/browser history?

Or does this work similar to how the realtime API works with the same permission routers to check for member vs visitor and it retrieves id for both?

I am trying to figure out this use case different and how it can be applied in different scenarios.

Solid point. Here is the result:

When user directly enters to the API without going to website itself doesn’t matter that cookies blocked or enabled you won’t see any identity data like visitor id.

But scenario and usage of this API already should be done after the user enters to the site. And when user enters to the site doesn’t matter if they accept/block/deny cookies you’ll have a visitor id.

Because the main router (Wix’s Servers) must understand the user permissions and it’ll attach an id to user. So in any case you should get a visitor id if user visited site at least once.


You can test this:

Open the API in incognito mode and disable/block all/any cookies. You won’t see anything in the result it’ll be empty with an empty signedToken.

Then while cookies are blocked open the website itself (not the API). It’s just a basic template homepage. After that open/refresh the API and you must see visitor id there.

Website
API

1 Like

Do you have a method for validating the signed token?

I don’t think we can validate it since we don’t have the secret key but we can read the data in it.

In that case then I’d caution anyone reading this thread against using the visitor id/member id for authentication as it could be faked and according to the docs is readable by anyone.

It sounds like what you’d need though is for Wix to provide user authentication for these requests.

But also if these endpoints are being used on site why not use Velo Web Modules and getMember?

1 Like

Velo APIs only works with logged-in members and if you are trying to get an ID of logged-in member then you should use wix-member APIs but there isn’t a way to get visitor ids.

And I think in most cases it’s not important to have a faked visitor id. I wouldn’t store any sensitive data if user did not signed-in. We could just store some progress made or similar things that’s not important and only improves UX.

There is another way to get a visitor id which is creating an empty item in a collection with wix-data APIs and then you can get the _owner field which will hold the visitor id if user did not signed-in yet. This _owner field value will be the same with visitor id.

In the end as you said it’s not secure to use visitor ids (or member ids) for auth process.

When you want to return a sensitive data based on visitor or member id you should use Velo APIs in the backend. With currentMember APIs.

Let me know if I’m missing something :thinking:

1 Like

I agree. You’re not missing anything. Just wanted to clarify some points for anyone else reading along.

1 Like

Not sure about this but I think user ids in headers cannot be faked and it’s always overwritten by Wix. So in this case we don’t need to validate the token we can trust the value in it.

Not sure about this but after I made few tests it’s not possible to fake any header value that’s generated by Wix. Wix servers will overwrite these values.

I’m just returning the request itself and I can’t change that value Wix overwrites it when routing the request to the relevant place.

So if this is the case I think we can trust the value without needing to validate JWT tokens. I’m not sure about this it would be good if someone from Wix verify this.

1 Like

Interesting. I’ll try to see if I can get confirmation on this.

Any news about this? @anthony

I haven’t heard back yet. Will let you know when I do!

1 Like