Custom Domains

Run your links and pages on your own domain instead of the default {handle}.10x.in.

What you provide vs what 10x returns

How it works

1. Create domain mapping

   Register your domain in 10x with a default handle.

2. Save verification values

   Capture verification.txtName and verification.txtValue from the create response.

3. Run initial reconcile

   Trigger reconcile so 10x provisions hosted-zone metadata and nameservers.

4. Update DNS at registrar and delegated zone

   Delegate nameservers at your registrar, then add verification/traffic records in DNS.

5. Reconcile again

   Trigger reconcile after propagation.

6. Go live

   Domain becomes ACTIVE; public routing and redirects start resolving on your domain.

What custom domains do not cover

Custom domains currently support:

• public site traffic
• redirect/link traffic
• domain lookup and route activation

Custom-domain route actions also support advanced routing rules:

• proxy_origin.originUrl must start with https:// and cannot include credentials, query strings, or hash fragments.
• redirect.targetUrl must start with https://; redirect status codes are limited to 301, 302, 307, and 308.
• fallback can dispatch to a handle or proxy to an origin. Fallback redirects are intentionally excluded so unmatched paths do not unexpectedly redirect an entire domain.

Custom domains do not currently support:

• MCP endpoints on *.mcp.<your-domain>
• OAuth protected-resource metadata on your domain for MCP
• per-handle MCP subdomain routing under your registrar-managed domain

Why MCP is excluded from custom domains

MCP transport depends on platform-managed wildcard DNS, certificates, OAuth discovery metadata, and handle-routing rules on the environment domain. Supporting https://{handle}.mcp.<your-domain> would require extra wildcard delegation, certificate issuance, and environment-specific OAuth metadata hosting for every customer domain. That is not part of the supported custom-domain flow today.

Domain Commerce UI screens

Use these screens in order inside Domain Management:

Screen 1: Create domain result

Immediately save:

• verification.txtName
• verification.txtValue (one-time)

Screen 2: Registrar records panel

Add exactly these records:

Screen 3: Status timeline

Expected transition order: PENDING_DELEGATION -> (PENDING_CERT or PENDING_EDGE_DEPLOY) -> ACTIVE

If a status stalls, use statusReason as the fix instruction. Some PENDING_CAPACITY reasons are operator-only infrastructure issues, not customer DNS mistakes.

Operator-only shard status reasons

DNS values you must configure

1) Registrar nameserver delegation

Use the nameservers[] values returned by GET /v2/account/domains/{domain} after reconcile.

2) Verification TXT record

Use the values returned in the create response:

3) Traffic record in delegated DNS zone

Add a traffic record in the delegated zone so requests route to 10x edge.

Set up a custom domain

Verify routing

Domain lookup contract

curl -sS "https://ai.10x.in/v2/public/domain-lookup?domain=example.com"

Expected:

• 200
• status: "ACTIVE"
• handle matches your defaultHandle

Redirect behavior check

Create a known slug on the mapped handle, then request:

https://example.com/<slug>

Expect redirect response (302 or 307) to the configured destination URL.

Route actions and fallback origins

Account domains support ordered route rules for production-domain composition. Each rule matches a path prefix and applies one action:

• dispatch_handle: serve the path through a 10x handle.
• proxy_origin: proxy the path to an external HTTPS origin.
• redirect: send the viewer to a fixed HTTPS URL with status 301, 302, 307, or 308.

If no route rule matches, the domain uses its fallback. A fallback can dispatch to a handle or proxy to an external HTTPS origin. Existing domains that only have defaultHandle and pathRules continue to work; those legacy path rules are treated as handle-dispatch rules.

Example:

{
  "defaultHandle": "main",
  "routeRules": [
    {
      "id": "rule_shop",
      "match": { "type": "prefix", "value": "/shop" },
      "action": { "type": "dispatch_handle", "handle": "shop" },
      "order": 10,
      "enabled": true
    },
    {
      "id": "rule_blog",
      "match": { "type": "prefix", "value": "/blog" },
      "action": {
        "type": "proxy_origin",
        "originUrl": "https://legacy.example-host.com",
        "preserveHostHeader": false
      },
      "order": 20,
      "enabled": true
    }
  ],
  "fallback": {
    "type": "proxy_origin",
    "originUrl": "https://current-site.example.com",
    "preserveHostHeader": false
  }
}

Required auth and access

• OWNER-level JWT for domain create/reconcile/routes.
• Registrar access to update nameservers for your domain.
• DNS access to add TXT and traffic records in the delegated zone.

Status and statusReason guide

Troubleshooting DNS issues

• Reconcile still awaiting_nameserver_delegation: check authoritative NS with dig +short NS <domain>.
• Reconcile still awaiting_txt_ownership_verification: check TXT with dig +short TXT <txtName>.
• edge_record_not_ready: verify only one canonical traffic record exists for host and points to platform target.
• FAILED/custom_domain_reconcile_error: re-run reconcile, then escalate with response payload and timestamp.

Related