Data & Permissions Management
Memberstack works by attaching a JavaScript layer (via a script tag) to a front-end site — most commonly Webflow, though it works with any HTML/JS site — rather than running as a backend framework, so its permission model is expressed through data attributes (like data-ms-content tied to a Plan ID) placed directly on page elements. Members are assigned to one or more Plans, and Plans are what content Rules actually key off, with free and paid Plans able to carry Stripe-based billing when you want to gate by subscription rather than a one-time login.
Practical Details
Custom Fields, defined per-member in the Memberstack dashboard, let you store arbitrary member data (onboarding answers, account metadata, usage flags) that's readable both client-side through the Memberstack DOM package (window.$memberstackDom) and via webhooks to Zapier, Make, or a custom endpoint. Because gating happens client-side by hiding or showing DOM elements after the page loads, gated content is technically present in the page's initial HTML before Memberstack's script runs — a real limitation for static site builders like Webflow, where a brief flash of gated content or its presence in page source is possible, so nothing truly sensitive should be embedded directly in gated markup. Plan changes (upgrades, downgrades, cancellations) sync through Stripe webhooks back into a member's Memberstack record, which is what other Rules and Custom Field logic key off going forward.
Actionable Considerations
- Don't place genuinely sensitive data directly in gated page HTML — client-side gating can briefly expose or leak it in page source on static builders like Webflow.
- Use Custom Fields plus webhooks (Zapier/Make) rather than DOM scraping when you need member data synced to an external system.
- Verify Stripe webhook delivery is configured correctly, since Plan status changes depend on webhooks reaching Memberstack reliably.