URL forwarding and redirects

There are two redirect models on DomainGenius:

• Single redirect (update_domain_settings.redirect_url) — sends every request to one target URL. Easy, no rules.
• Per-path rules (/v1/domains/{domain}/redirects) — rule list with patterns and priority. Useful for multi-path migrations.

Both run on Cloudflare Workers at the edge — sub-50ms TTFB worldwide.

Single redirect

curl -X PATCH "https://api.domaingenius.com.au/api/v1/orgs/$DG_ORG/domains/old-brand.com.au" \
  -H "Authorization: Bearer $DG_KEY" \
  -d '{ "redirect_url": "https://new-brand.com.au" }'

Path is preserved by default — old-brand.com.au/about becomes new-brand.com.au/about. Set redirect_url to an empty string to remove.

Path-based rules

curl -X POST "https://api.domaingenius.com.au/api/v1/domains/old-brand.com.au/redirects" \
  -H "Authorization: Bearer $DG_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "match": "/blog/*",
    "destination": "https://new-blog.com/$1",
    "status": 301
  }'

$1, $2, … refer to glob captures. Order rules with PATCH /priorities:

curl -X PATCH "https://api.domaingenius.com.au/api/v1/domains/old-brand.com.au/redirects/priorities" \
  -d '{ "order": ["redir_001", "redir_002", "redir_003"] }'

Lowest-index rule that matches wins. Catch-all rule should be last.

301 vs 302

301 (permanent) is cached aggressively by browsers — once a user has hit the redirect, their browser may not check back for months. Use it when you’ve decided. 302 (temporary) is not cached — use it during a migration window where you might roll back.

What you can’t do

• Redirect with a request body intact — redirects are always GET-after-redirect.
• Forward to a non-http(s) URL.
• Add custom headers on the redirected response.

For those cases, point the domain at your own server with a CNAME and handle the redirect there.