Velo by Wix: Adding Custom Code, Databases, and APIs to Your Wix Site

Velo by Wix is the answer to the question every growing Wix site eventually asks: what happens when the drag-and-drop tools run out? Velo is Wix's full-stack development platform, built directly into the editor. It gives you JavaScript on the page, JavaScript on the backend, a built-in database, and the ability to call external APIs, all hosted and deployed by Wix with no servers to manage. If you can write JavaScript, Velo turns a Wix site from a brochure into an application platform, and in 2026 it remains the feature that most separates Wix from simpler site builders.

What Velo actually includes

Turning on developer tools in a Wix site (or working in Wix Studio's code environment) unlocks several distinct capabilities that work together:

• Page code. Every page gets a JavaScript file where you respond to events, manipulate elements through the $w selector API, show and hide content, and build dynamic behavior the editor alone cannot express.
• Backend code. Web modules run on Wix's servers, keeping secrets and business logic off the browser. Frontend code calls backend functions with a simple import, and Wix handles the transport.
• Content collections. A built-in database (the Content Management System, or CMS) stores structured content in collections that behave like tables, with permissions, references between collections, and a query API.
• Dynamic pages. Collections can drive page generation, so one layout plus two hundred rows becomes two hundred URLs, each with its own content and SEO settings.
• HTTP functions and integrations. You can expose your own REST endpoints from a Wix site, receive webhooks, call third-party APIs with the Fetch API, schedule background jobs, and store API keys in a secrets manager.

Everything deploys instantly when you publish. There is no build pipeline, no hosting configuration, and no dependency server to patch, which is precisely the trade: you accept Wix's runtime and its constraints in exchange for never thinking about infrastructure.

Working with page code and $w

The heart of frontend Velo is the $w API. Every element you place in the editor gets an ID, and your code selects and controls elements by that ID. A minimal example that reacts to a button click looks like this:

import wixLocationFrontend from 'wix-location-frontend';

$w.onReady(function () {
    $w('#subscribeButton').onClick(() => {
        const email = $w('#emailInput').value;
        if (!email.includes('@')) {
            $w('#errorText').text = 'Please enter a valid email.';
            $w('#errorText').show();
            return;
        }
        wixLocationFrontend.to('/thank-you');
    });
});

The pattern scales up naturally: repeaters bind lists of data to repeating layouts, lightboxes open programmatically, and form inputs validate before submission. The discipline that matters is naming your element IDs meaningfully in the editor, because #button14 in code six months later is a small tragedy of your own making.

Collections and dynamic pages

The CMS is where Velo starts paying for itself on content-heavy sites. Suppose you run a consultancy with thirty case studies. Instead of thirty hand-built pages, you create a CaseStudies collection with fields for title, client, industry, summary, and body, then build one dynamic page layout bound to the collection. Wix generates a URL per item, and adding a case study becomes a data-entry task rather than a design task.

Code can query collections directly with wix-data. A backend function that returns recent items looks like this:

import wixData from 'wix-data';

export async function getRecentCaseStudies(limit = 6) {
    const results = await wixData.query('CaseStudies')
        .descending('_createdDate')
        .limit(limit)
        .find();
    return results.items;
}

Collection permissions deserve early attention. Each collection defines who can read, insert, update, and delete, and the defaults are conservative on purpose. Backend code can bypass permissions explicitly when justified, which is powerful and therefore worth using sparingly and documenting when you do.

Calling external APIs safely

Most real Velo projects eventually talk to an outside service: a CRM, a shipping-rate API, a payment provider, an internal system. The correct pattern is always the same: the browser calls your backend web module, and the backend calls the external API using a key stored in the Secrets Manager. Keys never appear in frontend code, which is visible to anyone who opens developer tools.

// backend/crm.web.js
import { Permissions, webMethod } from 'wix-web-module';
import { getSecret } from 'wix-secrets-backend';
import { fetch } from 'wix-fetch';

export const addLead = webMethod(Permissions.Anyone, async (email) => {
    const apiKey = await getSecret('crmApiKey');
    const response = await fetch('https://api.example-crm.com/leads', {
        method: 'post',
        headers: {
            'Authorization': 'Bearer ' + apiKey,
            'Content-Type': 'application/json'
        },
        body: JSON.stringify({ email })
    });
    return response.ok;
});

In the other direction, HTTP functions let external systems call your site, which covers webhooks from payment processors, form tools, and automation platforms. Between outbound fetch, inbound HTTP functions, and scheduled jobs, most integration architectures are expressible without leaving Wix.

Where Velo shines and where it strains

Velo is at its best in the middle ground between a static site and a custom application: member areas with personalized content, quote calculators, searchable directories, gated resources, dashboards fed by collections, and integrations that move data between your site and your business systems. Teams ship these in days because the hosting, auth, and database questions are already answered.

Be honest about the ceiling. You are working inside Wix's runtime, so you cannot install arbitrary server software, tune the database engine, or take the rendering pipeline apart. Very large datasets, heavy computation, and applications where the site is incidental to the software are better served by a dedicated stack, possibly with Wix Headless consuming Wix business APIs from your own frontend. Source control also requires intent: Wix offers a GitHub integration and a local development workflow with its CLI, and any team beyond one developer should adopt them rather than editing production in the browser.

Getting started the right way

Start smaller than you think. Pick one real problem, such as a contact form that writes to a collection and notifies your CRM, and build it end to end: element IDs, page code, a backend module, a secret, and a test. That single loop teaches you eighty percent of the platform's shape. From there, adopt habits that keep a growing codebase sane: meaningful IDs, backend modules organized by domain, permissions reviewed per collection, and a staging clone of the site for anything risky.

The bottom line

Velo by Wix occupies a genuinely useful position: real JavaScript development with the infrastructure abstracted away. It will not replace a custom stack for heavy applications, and it does not need to. For the enormous category of business sites that need a database, some logic, and a few integrations, Velo delivers those capabilities inside the same platform the marketing team already uses, and that combination is why it remains one of the strongest arguments for choosing Wix.