Everything Furl
can do for your domain

Furl runs as an edge routing layer in front of your domain. It decides whether to serve a file, apply a redirect, proxy to a route destination, or fall back to your primary origin.

You get one control plane for domains, routes, experiments, analytics, and team access, without shipping deploy-time proxy code for every change.

Routes let you serve content from a completely different platform or server under a path on your main domain. When a visitor goes to mycompany.com/blog, Furl intercepts that request and proxies it to your WordPress instance — the URL in the browser never changes.

This is useful for keeping your domain cohesive while using best-of-breed tools for each section: Webflow or Framer for marketing pages, WordPress for blogs, and Squarespace or Wix for brochure sites.

How to set up a route

Configuration reference

Redirects are evaluated before routes and are ideal for handling URL migrations, canonical enforcement, and legacy link management. They're matched at the edge in under a millisecond with zero origin round-trips.

Pattern syntax

Furl supports three matching modes:

# Exact path
/old-about       → /about

# Named parameter (captures :slug)
/blog/:slug      → /articles/:slug

# Wildcard (captures everything after /news/)
/news/*          → https://press.mycompany.com/*

# Regex (isRegex: true)
^/products/([0-9]+)$ → /shop/item/$1

Furl operates as a reverse proxy in front of your domain. To use it, you point your domain's DNS to Furl's infrastructure. We handle SSL certificate provisioning via Cloudflare for SaaS — you don't need to touch your certificate configuration.

Required DNS records

Domain types

SSL / TLS

SSL certificates are provisioned automatically by Cloudflare when your domain is verified. Certificates use DV (Domain Validated) TLS, enforce a minimum of TLS 1.2, and are renewed automatically. You don't need to manage certificates, upload anything, or renew manually.

Furl's A/B testing works at the proxy layer — no JavaScript, no flicker, no client-side redirects. Visitors are assigned to a variant before the first byte is served. Assignments are sticky: the same visitor always sees the same variant across sessions, using a cookie-based approach.

Traffic splitting

Conversion tracking

Statistical significance

Furl uses a two-proportion z-test to calculate statistical confidence. A minimum of 100 visitors per variant is required before confidence is calculated. When confidence reaches your configured threshold (default 95%), Furl will display the winning variant and — if Auto-Switch is enabled — automatically route 100% of traffic to the winner and close the test.

Sticky sessions & the variant cookie

furl_ab_{testId}=a; Path=/; Max-Age=2592000; SameSite=Lax; Secure

The cookie contains only the variant letter (a or b) and expires after 30 days. It carries no personal identifier and cannot track visitors across sites.

Furl collects analytics directly at the edge, as every request passes through the proxy. There's nothing to install on your origin — no script tag, no pixel, no SDK. Analytics work immediately when your domain is live.

What's collected per request

b1
domainIdYour domain workspace identifiere.g. "clx8..."
b2
hostnameRequest hostnamee.g. "mycompany.com"
b3
pathURL pathe.g. "/blog/my-post"
b4
routeMatched route rulee.g. "/blog"
b5
sourceTraffic sourcee.g. "google"
b6
mediumTraffic mediume.g. "organic"
b7
countryCountry code onlye.g. "US"
b8
deviceDevice type"desktop" | "mobile" | "tablet"
b9
visitorHashDaily rotating hash — not an IPResets at midnight UTC
b10
referrerReferrer hostname onlye.g. "twitter.com"

Available metrics

• Visitors — unique daily visitor counts (by hash), with 7d / 30d / 90d windows
• Pageviews — total request count per path and per route
• Traffic by route — breakdown of visitors per route path (e.g. how many hit /blog vs /docs)
• Top pages — most visited URLs on your domain
• Traffic sources — UTM-parsed or referrer-parsed source/medium
• Device split — desktop / mobile / tablet percentages
• Geo distribution — country-level visitor map
• Real-time visitors — active visitors in the last 5 minutes, updated live

Sometimes you need to serve a specific file at a specific path — a site verification file, robots.txt, a .well-known challenge, or a sitemap — but your origin platform doesn't give you access to the root filesystem. Furl's file serving solves this.

Uploaded files are stored in Cloudflare R2 and served by the proxy worker before requests reach your route rules or primary origin. File paths take highest priority in the routing chain.

Common use cases

• Google Search Console verification — serve /google-site-verification.html
• Custom robots.txt — override or supplement your platform's robots.txt from /robots.txt
• Apple app site association — serve /.well-known/apple-app-site-association for universal links
• Favicon override — serve /favicon.ico without modifying your origin
• Bing / Pinterest verification — any platform verification file at any root path

Furl supports two sitemap modes. Passthrough keeps your origin's sitemap behavior. Managed generates sitemap XML directly from your Furl configuration.

Plan access: Starter supports passthrough mode. Managed mode is available on Growth, Agency, and Enterprise plans.

Modes

Generation rules

FAQ

Furl uses a team-based model. When you create an account, a team is created automatically and you are its Owner. You can invite colleagues by email — they receive an invitation link that expires after 7 days.

White-labeling is available on Agency plans and above. It lets you present your own brand name, logo, and portal hostname for invited collaborators while Furl runs the routing infrastructure behind the scenes.

Invited users land in a collaborator shell scoped to the workspaces and permissions you grant. They can work on assigned domains and routes without needing full account-level settings.

Branding settings

Portal DNS setup

Local dev (/etc/hosts)

127.0.0.1 portal.agency.local

http://portal.agency.local:5173/auth

• Keep your web app running on port 5173.
• Use the same hostname in White-label settings as your hosts entry.
• Validate login and invite acceptance on the branded hostname.

Staging checklist

• Set brandPortalDomain for a staging team.
• Create a staging CNAME from the portal hostname to https://proxy.usefurl.com.
• Confirm DNS verification is active and SSL status is active.
• Open branded /auth and complete OTP + Google auth.
• Accept an invite from the branded host and verify collaborator shell branding.

API keys let you manage your Furl configuration from scripts, CI/CD pipelines, or integrations. Keys are scoped to a team and carry the permissions of the team member who created them.

Key format

furl_live_cjld2cjxh0000qzrmn831i7rn   # Live key (production)
furl_test_cjld2cyuq0000t3rmniod1foy   # Test key (sandbox)

Making authenticated requests

curl https://furl-api-staging.hexeldigitalstudio.workers.dev/trpc/routes.list \
                -H "Authorization: Bearer furl_live_YOUR_KEY" \
                -H "Content-Type: application/json" \
                -d '{"domainId":"YOUR_DOMAIN_ID"}'

Webhooks let you build integrations on top of Furl events. When a domain is verified, an A/B test declares a winner, or a route changes, Furl sends an HMAC-signed POST request to your configured endpoint.

Available events

• domain.verified — fired when a domain's DNS verification succeeds
• domain.error — fired when DNS verification fails after a successful state
• ab_test.winner_declared — fired when statistical significance is reached
• ab_test.started — fired when a test transitions to running
• route.created — fired when a new route rule is created
• route.updated — fired when a route rule changes
• route.deleted — fired when a route rule is removed
• redirect.created — fired when a redirect rule is created
• redirect.updated — fired when a redirect rule changes
• redirect.deleted — fired when a redirect rule is removed

Verifying webhook signatures

import crypto from 'crypto'

function verifyWebhook(payload, signature, timestamp, deliveryId, secret) {
  const expected = 'sha256=' + crypto
    .createHmac('sha256', secret)
    .update(`${timestamp}.${deliveryId}.${payload}`)
    .digest('hex')

  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(signature)
  )
}

// In your handler:
const sig = req.headers['x-furl-signature']
const timestamp = req.headers['x-furl-timestamp']
const deliveryId = req.headers['x-furl-delivery-id']
const valid = verifyWebhook(req.rawBody, sig, timestamp, deliveryId, WEBHOOK_SECRET)

Select the correct platform preset so rewrite behavior and header handling match your origin. Support is focused on the no-code platforms below, with optional advanced origins behind a flag.

Furl is strongest when routing no-code platform origins. Custom-origin support will return once the advanced flow is reintroduced.