I’m trying to implement persistent SiteGPT conversations for logged-in Wix members using Velo.
The goal is for a member to resume the same AI conversation across devices by linking a SiteGPT thread ID to their Wix member account rather than relying on browser/local storage persistence.
The intended workflow is:
Retrieve the logged-in Wix member ID
Check a Wix CMS/database collection for an existing SiteGPT thread ID
If no thread exists, create one via the SiteGPT API
Store the returned thread ID against the member
Initialise the SiteGPT JavaScript SDK with that stored thread ID so the conversation resumes across devices
What I’ve tried so far
Enabled Velo
Reviewed Wix web modules documentation
Reviewed wix-fetch backend documentation
Reviewed SiteGPT API v2 documentation and SDK docs
Confirmed with SiteGPT support that the widget can be initialised using a stored thread ID
Planned to use a backend web module to keep the SiteGPT API key server-side only
Extra context
I’m mainly looking for guidance on the cleanest architecture/pattern for:
calling the SiteGPT API from Wix backend code
storing/retrieving thread IDs
initialising the SiteGPT SDK after login
handling timing between Wix member authentication and widget initialisation
If anyone has implemented persistent external chatbot conversations tied to Wix Members, I’d love to hear how you approached it.
I think you’re pretty much there in terms of the setup!
A few extra things:
Use the secrets manage to store the API Key, and access it in the backend code with the Secrets SDK - Introduction | API Reference
I don’t know much about the SiteGPT, so you’ll either need to use a CMS collection or some sort of extended field on the current member to associate their thread ID with their user profile.
To answer each additional question:
Web Methods are what you’re looking for here - webMethod() - these are backend functions that can be called from the frontend of the site. You can pass information to them, and they can return info back to the frontend. I’d probably set the permissions to .SiteMember so that only members can call the function.
You’ll probably also want to use the currentMember on the backend, so that within the function, you get the members details and then can run the rest of the code based on that user - Get Member | SDK
If you store data in a CMS, double check the CMS permissions so that users are only able to access their own record.
Personally, I would create a custom login/signup flow, so that when a user registers, you can initiate all of the additional information you need surrounding the member at the time they create their account - Register | SDK
