Magic

Webflow sites that need login, gated content, or membership access require an external authentication layer. Sites that need user login, gated content, or membership access have no native way to identify visitors or manage sessions. Every Webflow site requiring user identity depends on a third-party solution.

Magic provides passwordless authentication through email one-time passwords, social logins, and SMS. Connecting Magic with Webflow gives you a login system where users authenticate without creating or remembering passwords, and each authenticated user is automatically provisioned with a non-custodial Web3 wallet. The integration runs through Webflow's custom code features and, for cases that need server-side token validation or CMS writes, a small middleware layer.

Developers and agencies building membership sites, gated content portals, Web3 dApp landing pages, or client dashboards on Webflow often use this integration. Product managers evaluating passwordless UX and Web3 founders who need wallet provisioning without MetaMask popups will also find it relevant.

How to integrate Magic with Webflow

What is Magic? Magic is a wallet infrastructure and embedded wallet SDK that provides passwordless authentication for web applications. Users log in via email OTP, social accounts (Google, Apple, Discord, GitHub, and others), or SMS, with each user automatically receiving a non-custodial Web3 wallet on authentication. Magic supports 30+ blockchain networks and holds SOC 2 Type 2, ISO 27001:2022, GDPR, CCPA, and HIPAA certifications.

Teams use Magic with Webflow when they need to add user login to a site without managing passwords or building authentication infrastructure from scratch. Common scenarios include content membership sites, token-gated communities, and SaaS sign-up flows where fewer signup steps matter.

You can integrate Magic with Webflow in 2 ways:

• Custom code integration handles client-side authentication setup, including the login form, session checks, and UI toggling, without a backend.
• The Webflow and Magic APIs give you full control over server-side token validation, CMS user syncing, and webhook-driven workflows, but require a middleware layer.

Most implementations combine both methods. Client-side code handles the login experience, while a serverless function manages token validation and CMS writes.

Add Magic authentication with custom code

Magic does not have a Webflow Marketplace app. Integration happens entirely through Webflow's custom code features: custom code in head and body tags for site-wide scripts, page-level code for auth guards, and Code Embed elements for login forms. This approach handles basic passwordless login, session persistence, and client-side content gating without a backend. A paid Webflow site plan is required because custom code injection is unavailable on the free Starter plan.

Set up your Magic account and configure your Webflow site domains before writing code:

1. Create a Magic account at dashboard.magic.link/signup and create a new app.
2. Copy the Publishable API Key (pk_live_...) from the Magic Dashboard.
3. Add your Webflow site's published domain (and staging domain, if applicable) to the Domain Allowlist under Settings > Allowed Origins & Redirects in the Magic Dashboard.

The integration then covers three parts: loading the SDK, building the login form, and adding session checks.

Load the Magic SDK

The Magic JavaScript SDK needs to load on every page where authentication is relevant. Add it as a site-wide script so it is available across your Webflow site.

Magic's official JavaScript SDK reference documents npm installation rather than a Webflow-specific browser-loading setup. In Webflow projects without a build step, teams may use a script tag in custom code, but that browser-loading approach and exact delivery URL should be verified against current Magic docs before deployment.

Magic's documented initialization pattern is:

import { Magic } from 'magic-sdk';
const magic = new Magic('YOUR_PUBLISHABLE_KEY');

In Webflow, place the SDK load in Site settings > Custom Code so it is available site-wide, then initialize Magic in footer code with your Publishable API Key once the SDK is available.

Only the Publishable API Key (pk_live_...) should appear in Webflow custom code. The Secret Key must never be placed in any client-side code because it is visible in browser developer tools. Once the SDK is loaded site-wide, you can use the same magic instance across your login and protected pages.

Build the login form

The login form collects the user's email and triggers Magic's OTP authentication. You can build this with a native Webflow form element or a Code Embed element on your login page.

To set up the login form:

1. Add a Code Embed element to your login page with the following HTML:

<div id="magic-login">
  <input type="email" id="email-input" placeholder="Enter your email" />
  <button id="login-btn">Log in</button>
</div>

2. Add the authentication handler in the login page's Page Settings > Before </body> tag field:

<script>
  document.getElementById('login-btn').addEventListener('click', async () => {
    const email = document.getElementById('email-input').value;
    try {
      await magic.auth.loginWithEmailOTP({ email });
      window.location.href = '/dashboard';
    } catch (err) {
      console.error('Login failed:', err);
    }
  });
</script>

3. Publish the site and test the flow with test+success@magic.link (a Magic test email that simulates successful authentication without sending a real email).

loginWithEmailOTP() is the recommended approach. An older method called loginWithMagicLink() was deprecated in SDK v17.1.4 (May 2023). Tutorials published before mid-2023, including Magic's own Webflow tutorial, reference the deprecated method. Use loginWithEmailOTP() for all new implementations.

Add session checks to protected pages

Webflow does not enforce authentication on any page. Client-side JavaScript must check the user's session on every page that should be restricted and redirect unauthenticated visitors.

To protect a page:

1. Open the page's settings in Webflow (Pages panel > gear icon > Page Settings).
2. Add the following script in the Before </body> tag field:

<script>
  (async function() {
    const loggedIn = await magic.user.isLoggedIn();
    if (!loggedIn) {
      window.location.href = '/login';
    }
  })();
</script>

3. For content you want to hide until authentication is confirmed, assign a CSS class with display: none to those sections. Then update the script to reveal them when the session is valid:

<script>
  (async function() {
    const loggedIn = await magic.user.isLoggedIn();
    if (!loggedIn) {
      window.location.href = '/login';
    } else {
      document.querySelectorAll('.gated-content').forEach(el => {
        el.style.display = 'block';
      });
    }
  })();
</script>

4. To add a logout button, call magic.user.logout() and clear any stored session data:

document.getElementById('logout-btn').addEventListener('click', async () => {
  await magic.user.logout();
  localStorage.removeItem('magicSession');
  window.location.href = '/login';
});

Client-side content gating has a security limitation: the hidden content still exists in the page's DOM and can be inspected by technically sophisticated users. For content that must be genuinely secured (API responses, downloadable files, subscription-only data), server-side token validation through the API integration path is required.

One configuration note: if the Asynchronously load JavaScript option is enabled in Webflow's advanced publishing settings, the Magic SDK may not initialize in time. Wrap initialization in a DOMContentLoaded listener or disable the async option to avoid race conditions.

Build with the Webflow and Magic APIs

For production applications that need server-side token validation, writing user data to Webflow CMS, or webhook-driven workflows, both APIs connect through a middleware layer. Webflow is a static frontend host, so server-side code (Node.js, Python) cannot run within Webflow itself. A serverless function on Cloudflare Workers, Vercel, or AWS Lambda handles the backend logic.

This path uses these APIs and SDKs:

• Magic's JavaScript SDK handles client-side authentication and session management
• Magic's Node.js Admin SDK validates DID tokens and retrieves user metadata server-side
• Webflow's Data API v2 handles CMS collection reads and writes
• Webflow webhooks trigger real-time events when CMS items change or forms are submitted

The DID token returned by Magic's SDK has a default lifespan of 15 minutes. Your middleware validates that token using the Admin SDK's magic.token.validate() method, then issues its own session token (JWT or cookie) to the browser. That server-side check separates this approach from client-side-only integration.

Validate DID tokens with middleware

After a user authenticates on the Webflow frontend, the browser sends the DID token to your middleware for validation. The middleware then returns a session token that the browser stores for subsequent requests.

To implement token validation:

1. Install Magic's server-side Admin SDK in your middleware project:

npm install @magic-sdk/admin

2. Create a /api/login endpoint that validates the DID token and retrieves user metadata:

const { Magic } = require('@magic-sdk/admin');
const magic = new Magic(process.env.MAGIC_SECRET_KEY);

async function handleLogin(req, res) {
  const didToken = req.headers.authorization.replace('Bearer ', '');
  magic.token.validate(didToken);
  const metadata = await magic.users.getMetadataByToken(didToken);
  // metadata contains: issuer, email, publicAddress
  // Issue your own session token here
  res.json({ user: metadata });
}

3. On the Webflow frontend, update your login handler to send the DID token to the middleware:

const didToken = await magic.auth.loginWithEmailOTP({ email });
const response = await fetch('https://your-middleware.com/api/login', {
  method: 'POST',
  headers: { Authorization: `Bearer ${didToken}` }
});

Use the issuer field from the metadata response as your unique user identifier. The issuer is a persistent ID in the format did:ethr:0x... that remains constant across sessions. Do not use the DID token itself as a database key because it expires after 15 minutes. That distinction makes the middleware layer reliable for repeat logins and downstream syncing.

Sync authenticated users to Webflow CMS

After validating a user's identity, your middleware can create or update a member record in a Webflow CMS collection. This enables Collection List elements to display member-specific data, access tier badges, or activity logs.

To sync users to the CMS:

1. Create a "Members" CMS collection in Webflow with fields for email (plain text), magic-issuer (plain text), wallet-address (plain text), membership-tier (option), last-login (date), and access-granted (switch).
2. In your middleware, check whether the user already exists and create or update accordingly:

// Look up existing member by email
const existing = await fetch(
  `https://api.webflow.com/v2/collections/${COLLECTION_ID}/items/live`,
  { headers: { Authorization: `Bearer ${WEBFLOW_TOKEN}` } }
);

// If not found, create a new member record
await fetch(
  `https://api.webflow.com/v2/collections/${COLLECTION_ID}/items/live`,
  {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${WEBFLOW_TOKEN}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      fieldData: {
        name: metadata.email,
        email: metadata.email,
        'magic-issuer': metadata.issuer,
        'wallet-address': metadata.publicAddress,
        'last-login': new Date().toISOString(),
        'access-granted': true
      }
    })
  }
);

3. Register a Webflow webhook to trigger downstream actions (welcome email, Slack notification) when a new member record is created:

await fetch(
  `https://api.webflow.com/v2/sites/${SITE_ID}/webhooks`,
  {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${WEBFLOW_TOKEN}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      triggerType: 'collection_item_created',
      url: 'https://your-middleware.com/webhooks/new-member'
    })
  }
);

Webflow CMS API writes cannot happen from the browser. Webflow's CORS restrictions block client-side API calls to Webflow resources in production. All CMS writes must route through your middleware. Plan your member collection size according to your Webflow plan's CMS item limits, which vary by tier - consult webflow.com/pricing for current limits. In practice, that makes the middleware responsible for both security and data synchronization.

Magic does not publish outbound webhooks. The integration model is pull-based: your middleware retrieves user data from Magic at authentication time and pushes it to Webflow's CMS. Webflow webhooks (collection_item_created, collection_item_changed, form_submission) then trigger any downstream workflows when CMS records change.

What you can build with the Magic Webflow integration

Integrating Magic with Webflow lets you add passwordless user authentication and gated experiences to any Webflow site without managing passwords or building login infrastructure from scratch.

• Gated content membership site: Build a publication or course platform where readers authenticate with email OTP to access premium articles stored in the Webflow CMS. Magic handles login, your middleware checks access tiers, and Collection List elements render member-only content based on the CMS access flag.
• Web3 dApp onboarding page: Use a Webflow marketing site as the front door for a Web3 application. Users sign in with email or social accounts, Magic auto-provisions a non-custodial wallet on 30+ blockchain networks, and no MetaMask popup or seed phrase is required for first-time users.
• Token-gated community portal: Gate sections of a Webflow site behind NFT ownership verification. After Magic authentication, your middleware reads the user's wallet address, queries the blockchain for token balance, and updates the CMS member record's access flag to reveal or hide community content.
• Client dashboard with passwordless access: Create a client-facing portal where agency clients or business partners log in via email OTP without resetting forgotten passwords. Magic sessions persist for up to 7 days (configurable to 90 days), reducing repeat login friction for infrequent visitors.

If you need more control over membership lifecycle management, CMS-driven access tiers, or real-time webhook responses to authentication events, the API integration path covers those cases with control over those workflows.