Reverse Proxy Setup

Serve your Partner Fleet marketplace under your own domain.

What a reverse proxy is

By default, your marketplace is served from a hostname we provide. A reverse proxy lets you serve it from a subdirectory of your own domain instead:

https://www.yourcompany.com/partners/acme-integration

A visitor requests a page under your marketplace path. Your infrastructure recognizes the path, fetches the response from the Partner Fleet origin, and returns it under your domain. No redirect occurs, and the visitor never sees a Partner Fleet hostname.

Visitor  →  www.yourcompany.com/partners/acme
              ↓
         Your proxy layer (matches /partners/*)
              ↓
         Partner Fleet origin
              ↓
         Response served as www.yourcompany.com/partners/acme

Everything outside your chosen path continues to hit your normal infrastructure. Nothing about the rest of your site changes.

This resolution happens at request time, not build time. If your site is a static or hybrid build that pulls content at deploy, the proxy does not work that way: each request is evaluated live at your edge. Whether responses are then cached is a separate configuration layer that behaves the same as the rest of your caching.

Why it's valuable

• SEO accrues to your domain. Every marketplace page, listing, and category page builds authority on your core domain rather than on a separate property.
• Seamless brand experience. Visitors start on your domain and stay on it. The address bar never changes.
• AI discoverability. Search engines and AI assistants treat the marketplace as part of your site, and our answer-engine output (markdown page representations, llms-full.txt, structured data, sitemap) is indexed against your domain.
• Fully reversible. Remove the proxy rule and traffic returns to normal immediately; the marketplace stays available at its Partner Fleet hostname. Nothing is lost.

The two origin hostnames

Your proxy points at different origins in dev and production:

Build and prove your proxy against the partnerfleet.app hostname. At go-live, your IT team creates the CNAME record, we confirm it's active, and you swap the origin value in your proxy config. If your deployment pipeline uses environment variables, wire the dev origin to staging and the CNAME to prod so each environment only ever talks to the right instance.

We'll give you the exact values for both during onboarding.

Where the change lives

The proxy rule lives somewhere in your infrastructure, and we don't need access to anything on your side. The first question to answer, explicitly, is who actually controls your edge. The answer is often not the obvious one: many teams reach their CDN through a hosting platform or CMS vendor and don't have direct dashboard access to it.

Common insertion points, roughly in order of speed:

Any of these is a legitimate answer. Not having direct CDN access does not block the project. It just changes where you insert the proxy. Decide which layer you have real control over before writing any configuration, and tell your Partner Fleet contact which you've chosen.

Before you build anything

1. Pick your URL structure. /partners, /integrations, and /marketplace are all common. Confirm the path isn't already in use on your site, including as a redirect or CMS page. If you have multiple partner types that each need their own landing page, decide now whether they're categories within one marketplace (one proxied path) or separate marketplaces (separate proxied routes, which you should raise with your account contact, as it has commercial implications). This determines your route patterns.

2. Tell us your path before building. This is the step teams most often miss. We configure your marketplace to generate all internal links, asset URLs, canonical tags, sitemap entries, and form actions using your path prefix. Until we do, the page will load but styling, navigation, and deep links will be broken.

3. Ask for a sandbox. We recommend building against a separate sandbox instance rather than production, so your team can iterate and share work-in-progress without publishing anything. When you're ready, we copy the configuration across.

How to configure it

Whatever tool you use, the proxy rule does the same four things:

1. Match your marketplace path, both the bare path (/partners) and everything beneath it (/partners/*). Both are required: one catches the landing page, the other catches every listing. Avoid an overly loose pattern like /partners*, which would also capture /partnerships or /partner-program.

2. Forward to the Partner Fleet origin, stripping your path prefix and preserving everything beneath it plus the query string. Your path maps to the root of our origin: /partners renders our /, and /partners/acme renders our /acme.

3. Set forwarding headers. Set the Host header per our instructions (we'll tell you whether to replace it with the origin hostname or preserve yours), plus X-Forwarded-Proto: https. Also set CF-Worker to your public hostname (this is what makes generated links and CTAs use your domain) and forward the visitor's real IP in CF-Connecting-IP so marketplace analytics reflect actual visitors rather than your edge's address.

4. Rewrite redirects. If the origin issues a redirect, rewrite the Location header so the origin hostname is replaced with yours. Otherwise a redirect can briefly expose the origin hostname in the address bar. If your tool can't do this (some declarative rules engines can't), use a code-based option like an edge function or worker.

Reference implementation as an edge worker. Adapt to your platform:

// Values provided by your Partner Fleet contact.
// Dev: yourcompany.partnerfleet.app
// Production: your CNAME, e.g. cname.yourcompany.com
const ORIGIN_HOST = "yourcompany.partnerfleet.app";
const PROXY_PATH = "/partners";

export default {
  async fetch(request) {
    const incomingUrl = new URL(request.url);

    const originUrl = new URL(request.url);
    originUrl.protocol = "https:";
    originUrl.hostname = ORIGIN_HOST;
    originUrl.port = "";
    // Your path maps to the origin root: /partners/acme -> /acme
    originUrl.pathname = incomingUrl.pathname.slice(PROXY_PATH.length) || "/";

    const originRequest = new Request(originUrl.toString(), request);
    originRequest.headers.set("Host", ORIGIN_HOST);
    originRequest.headers.set("X-Forwarded-Proto", "https");
    // Tells Partner Fleet which public base to generate links from.
    originRequest.headers.set("CF-Worker", incomingUrl.hostname);
    // Real visitor IP, or all marketplace analytics record your edge.
    originRequest.headers.set(
      "CF-Connecting-IP",
      request.headers.get("CF-Connecting-IP")
    );

    const originResponse = await fetch(originRequest, { redirect: "manual" });
    const response = new Response(originResponse.body, originResponse);

    const location = response.headers.get("Location");
    if (location) {
      response.headers.set(
        "Location",
        location.replace(
          new RegExp(`https?://${ORIGIN_HOST}`, "i"),
          `https://${incomingUrl.hostname}${PROXY_PATH}`
        )
      );
    }

    return response;
  },
};

We have platform-specific guidance for common setups. Ask your Partner Fleet contact.

Caveats

Traffic must actually flow through the layer where your rule lives. In Cloudflare terms, the DNS record needs to be Proxied, not DNS Only, or a Worker route will never fire. The equivalent applies on any platform: a rule at a layer traffic doesn't pass through does nothing.

Caching. Your edge's cache rules apply to the proxied path like any other. Confirm with whoever operates your CDN how existing rules behave before you build, and test what actually happens after a content change during your proof of concept. On some platforms, redeploying your site does not purge cached responses from external origins. Talk to us about cache TTLs before launch.

Bots and crawlers. Your marketplace exists to be found, including by AI assistants. We run bot protection, caching, and SEO/AEO output at our layer, and verified crawlers (Googlebot, Bingbot, ChatGPT, Claude) are allowed through. Since your proxy sits in front, your WAF and bot rules apply first. Check they don't block verified crawlers on the marketplace path. This is the most likely way to accidentally make your marketplace invisible to search.

SEO plumbing on your side. Reference the Partner Fleet sitemap from your root sitemap or sitemap index, submit it in Google Search Console under your primary domain property, and confirm your robots.txt permits the marketplace path.

CDN in front of CDN. If your edge and Partner Fleet use the same CDN vendor, you may hit friction. It's a known pattern, not a blocker. Try the standard setup first, and raise it with us if you get stuck rather than defaulting to a workaround.

Per-listing gating belongs in the app, not the router. Use the wildcard route. Listing approval inside Partner Fleet already controls what's publicly reachable, so duplicating that gate at the infrastructure layer means someone touches infrastructure every time a partner publishes.

Recommended sequence

1. Confirm your path and URL structure with Partner Fleet.
2. We apply the base path configuration and stand up your sandbox.
3. Your team builds the proxy rule against the sandbox (yourcompany.partnerfleet.app) in dev or staging.
4. Prove the core functionality: page loads, deep links, styling, and at least one live form submission end to end into your marketing automation platform.
5. At go-live, your IT team creates the production CNAME, we confirm it, and you promote the proxy config to production pointed at the CNAME.
6. We copy your marketplace configuration from sandbox to production.
7. Submit sitemaps and confirm indexing.

The technical path runs in parallel with your design, taxonomy, and content work. In practice the technical work resolves first, and content readiness usually determines the launch date.

Testing checklist

Test in an incognito window with a cleared cache.

• Marketplace landing page loads at your path
• An individual listing loads at its deep link
• A category or filtered page loads correctly
• Styling, images, logos, and fonts all render (broken styling usually means your public base isn't configured on our side, so contact us)
• Search and filtering work
• The address bar never shows a Partner Fleet hostname, including after clicking a CTA
• The address bar keeps your path prefix after clicking through to a listing and back
• A lead form submits successfully and the test lead arrives in your marketing automation platform (confirm the POST itself does not 404)
• A test visit from a known IP appears in marketplace analytics as that IP, not your edge's address
• External CTA links open the correct destination
• Pages outside the marketplace path are unaffected
• Sitemap resolves under your domain; canonical tags point at your domain
• robots.txt permits the path; your WAF doesn't block verified crawlers
• Mobile rendering is correct

Common issues

Rolling back

Remove the proxy routes. Traffic returns to your normal origin immediately and your marketplace stays fully available at its Partner Fleet hostname. If the subdirectory path has already been indexed, tell us before rolling back so we can coordinate redirects and protect your rankings.

Ongoing ownership

Once live, content changes, new listings, and approvals flow through automatically without anyone touching infrastructure.

Your side: uptime monitoring on the marketplace path; awareness that DNS, WAF, or routing changes on your zone can affect the proxy (worth a line in your runbook); telling us before changing the path so we can update the base path and issue redirects together.

Partner Fleet's side: the marketplace application, listing data, platform uptime, bot protection at our layer, SEO/AEO output, and any configuration you request.

Getting help

Reach out to your Partner Fleet implementation contact with:

• The full URL where you see the issue
• A screenshot or copy of the error
• Your CDN request or trace ID if one is shown
• Which layer you inserted the proxy at

The trace ID lets us follow the exact request, which usually saves a round trip.