A supplier’s own domain

On Pro, a supplier can set their own portal address in Settings → Branding, such as portal.theircompany.com or order.theircompany.com. The supplier is read from that host. A person still only sees a portal they belong to. Staff sign in on that same address and open the workspace there. Signing out returns to that address’s sign-in page. Buyers still open the trade portal.

Use portal. or order. rather than the bare domain. The bare domain is where the supplier’s email is set, and a CNAME there fights those mail records. The app refuses a bare name such as theircompany.com.

theirname.tradecatalog.app and tradecatalog.app/p/theirname keep working. Mail is still sent from orders@tradecatalog.app. Pages on the supplier’s own address send X-Robots-Tag: noindex. /mcp, /oauth and /api/v1 stay on tradecatalog.app.

Connect your addressLink to this section#

Open Settings → Branding → Your portal address on Pro.

1. Choose Use your branding to put your name, logo and colours on sign-in, the portal, emails and order documents. Service information stays on the sign-in page.
2. Enter an address such as portal.theircompany.com and choose Save address and branding. This saves the address and branding together and starts the check.
3. Add the CNAME shown at your DNS provider. Copy buttons copy the exact name and target. If your provider adds your domain automatically, enter only the part before your domain in Name.
4. Follow Address saved, Domain verified, and Secure connection. Hostname activation and certificate issuance are separate checks. A verified domain alone does not mean HTTPS is ready.
5. Checks refresh every 30 seconds for up to ten minutes while this page is visible. Choose Check connection again to retry after changing DNS or if automatic checks have paused.
6. Once Your certificate is ready appears, check that your CNAME points to the shown target and use Open your sign-in page to verify that your own portal opens securely before sharing it. Provider readiness does not independently verify where your registrar is sending traffic. Your existing portal link remains available throughout setup.

New addresses use automatic HTTP certificate validation. A connection check can safely retry a pending certificate on the same hostname, without deleting it. Older TXT setups can move to HTTP validation when eligible. Delegated and wildcard DNS validation retain their existing method.

When DNS validation is needed, all required TXT values are shown, including both values when two records share a name. Delegation CNAME records are an alternative when offered. Keep delegation records for renewals; a CNAME and TXT records cannot share the same name. For automatic HTTP validation, additional DNS verification records are available under Additional certificate verification records rather than presented as a required extra step.

The page shows the last check time and any problem reported by the certificate service. A failed retry keeps your current address and verification records. If you need help, use Get help connecting your address. You do not need to manage TradeCatalog's API credentials or look for a hidden platform button.

Leaving the saved address blank and choosing Remove address and save branding removes it. When the platform is connected to Cloudflare, the old custom hostname is removed there too. It does not change your registrar's DNS records.

For platform operatorsLink to this section#

The sections below describe TradeCatalog's infrastructure, not steps suppliers need to complete. The fallback origin and production catch-all route are configured separately. Do not change provider credentials or zone routes as part of following the supplier setup above.

Cloudflare for SaaSLink to this section#

Do this on the tradecatalog.app zone, by hand, when you are ready to switch custom domains on. Enable Cloudflare for SaaS for that zone first.

1. Fallback originLink to this section#

Custom-hostname traffic is sent to a fallback origin on your zone. For a Worker, that record is originless:

Then set the fallback origin to fallback.tradecatalog.app. In the dashboard that is SSL/TLS → Custom Hostnames → Fallback origin. With the API:

PUT /zones/{zone_id}/custom_hostnames/fallback_origin
{ "origin": "fallback.tradecatalog.app" }

Wait until that fallback origin is Active. See Workers as your fallback origin.

2. Worker routeLink to this section#

This is already in the production routes in wrangler.jsonc. Wrangler replaces routes on deploy, so removing it there would stop a supplier’s own domain reaching this Worker. Do not add it to staging.

{ "pattern": "*/*", "zone_name": "tradecatalog.app" }

That route sends every host that enters the zone to this Worker, including a customer’s own domain. More specific routes win, so leave the routes that are already there:

{ "pattern": "tradecatalog.app", "custom_domain": true }

{ "pattern": "*.tradecatalog.app/*", "zone_name": "tradecatalog.app" }

And leave the staging Worker’s route as it is:

{ "pattern": "staging.tradecatalog.app", "custom_domain": true }

Do not put */* on staging. Do not create a custom hostname equal to tradecatalog.app, www.tradecatalog.app, or fallback.tradecatalog.app.

3. Custom hostnames APILink to this section#

The app calls the custom hostnames API when a supplier checks an address, and only after these are set on the production Worker:

• CLOUDFLARE_API_TOKEN as a secret, with permission to edit custom hostnames and their certificates
• CLOUDFLARE_ZONE_ID as the tradecatalog.app zone id

POST /zones/{zone_id}/custom_hostnames
{
  "hostname": "portal.theircompany.com",
  "ssl": { "method": "http", "type": "dv", "settings": { "min_tls_version": "1.2" } }
}

Status polling uses GET /zones/{zone_id}/custom_hostnames/{id}. A supplier-initiated connection check can safely PATCH a pending provider-managed DV certificate and then read its status again, preserving its SSL settings. It never deletes or recreates a hostname. Active and uploaded custom certificates are not restarted, and delegated or wildcard validation stays TXT. Clearing or replacing an address sends DELETE for the previous id.

New addresses use HTTP certificate validation: once the CNAME points at the fallback origin, Cloudflare can validate automatically. Existing addresses keep their original validation method until it is changed.

Platform staff can run Check address for any business from that business’s customer account, and by opening the workspace and using Settings → Branding. Reset certificate validation is platform staff only. It asks Cloudflare to set the certificate method to HTTP. If Cloudflare will not change the method on the existing hostname, the hostname is removed and created again with the same address and certificate settings, and the new id is saved. The confirmation says that this changes the live Cloudflare custom hostname. While the reset runs, that confirm button says Resetting…, shows a spinner, and cannot be pressed again. Afterwards the page shows the status and any DNS records to send to the supplier. Check address on the customer account does the same while its check runs. A supplier owner cannot run the reset.

For an address still using TXT or delegation after a safe retry, the supplier chooses Check connection again, adds every certificate record shown under Add these records at the DNS provider, and checks again. DNS can be connected while the certificate still needs these records. Do not replace one TXT token with the other when two are shown. If delegation is offered, use its CNAME records instead of conflicting TXT records. The app does not redirect /.well-known/acme-challenge/ or /.well-known/pki-validation/ on that host. Leave those paths alone in any redirect rule, so a certificate check is not rewritten.

What the customer addsLink to this section#

A CNAME for portal.theircompany.com (or order.) pointing at fallback.tradecatalog.app.

Recommend that name. A bare domain such as theircompany.com cannot be a normal CNAME without moving mail, and Cloudflare’s apex proxying is a separate setup. Do not use it.