How to receive webhooks in Wix with Velo HTTP functions

Many services can notify your site when something happens: a payment succeeds, a form is submitted elsewhere, an order ships. They do it with a webhook, an HTTP request sent to a URL you give them. In Wix, that URL comes from Velo HTTP functions.

This guide builds an endpoint that receives order updates, checks they really come from your service, and saves them to a CMS collection.

1. Create the HTTP functions file

In the Velo sidebar, open the backend folder and add a file named exactly http-functions.js. Wix only looks for HTTP functions in this file.

Each exported function becomes an endpoint. The name starts with the HTTP method, then an underscore, then the endpoint name. post_orderWebhook answers POST requests to /_functions/orderWebhook.

2. Store a shared secret

Webhook URLs are public, so anyone who finds yours could send fake data. Most services let you set a secret token they include with every request. Add that token in Developer Tools → Secrets Manager as WEBHOOK_TOKEN.

3. Write the endpoint

import { ok, badRequest, forbidden } from "wix-http-functions";
import { getSecret } from "wix-secrets-backend";
import wixData from "wix-data";

export async function post_orderWebhook(request) {
  const token = request.headers["x-webhook-token"];
  const expected = await getSecret("WEBHOOK_TOKEN");
  if (!token || token !== expected) {
    return forbidden({ body: { error: "Invalid token" } });
  }

  let payload;
  try {
    payload = await request.body.json();
  } catch (error) {
    return badRequest({ body: { error: "Body must be JSON" } });
  }

  if (!payload.orderId || !payload.status) {
    return badRequest({ body: { error: "orderId and status are required" } });
  }

  await wixData.insert(
    "OrderUpdates",
    { orderId: payload.orderId, status: payload.status, receivedAt: new Date() },
    { suppressAuth: true }
  );

  return ok({ body: { received: true } });
}

What each part does:

• The token check rejects any request without the right secret, before the body is even read.
• badRequest responses tell the sending service what was wrong, which helps when you set the webhook up.
• suppressAuth: true lets the backend write to the collection even though the request doesn’t come from a logged-in member. Keep the collection’s permissions closed to site visitors.
• Returning ok quickly matters: many services retry or give up if your endpoint is slow.

The header name x-webhook-token is an example. Use whatever header your service documents. Some services sign the body instead of sending a token; in that case, follow their verification steps in the same place.

4. Find your endpoint URL

Once the site is published, the endpoint lives at:

• https://www.yourdomain.com/_functions/orderWebhook on a site with a custom domain
• https://username.wixsite.com/sitename/_functions/orderWebhook on a free Wix address

While you’re still testing, use _functions-dev instead of _functions to call the latest saved version without publishing.

5. Test it

Send a test request with any HTTP client, for example from a terminal:

curl -X POST "https://www.yourdomain.com/_functions-dev/orderWebhook" \
  -H "Content-Type: application/json" \
  -H "x-webhook-token: your-secret" \
  -d '{"orderId": "1001", "status": "shipped"}'

A {"received": true} response and a new row in OrderUpdates mean it works. Try a wrong token too, and check you get a 403.

When to go further

Real integrations usually add a check for duplicate deliveries, logging so failed webhooks are easy to trace, and code that acts on the data, such as emailing the customer or updating a member’s page.

If you need your Wix site connected to a payment, shipping or CRM service, I do custom API integrations for Wix.