Custom referral domains

Serve partner links from your own domain (refer.yourbrand.com) with automatic TLS.

By default every partner short link points at the platform domain (https://partli.app/r/<slug>). A custom referral domain lets you serve those same links from a subdomain of your own brand — e.g.https://refer.acme.com/r/<slug> — so the URLs your partners share look like they come from you. This is a workspace setting managed by anyone who can manage the workspace, and it requires the custom_domain plan feature.

The mechanism is a DNS CNAME: you point a subdomain at the app hostname, we verify DNS, then provision a TLS certificate for it. Because the/r/<slug> redirect is host-agnostic (slugs are globally unique), links just work from any verified domain.

In the dashboard

Open /<workspace>/settings and find the Custom referral domain card.

●
Add the DNS record at your registrar
Create a CNAME record for your chosen subdomain pointing at the app hostname (partli.app in production). For example:
```
Type   Name              Value
CNAME  refer.acme.com    partli.app
```
If your DNS provider flattens CNAMEs at the apex (e.g. Cloudflare), an A record pointing at the same IPs as the app hostname also passes verification.
●
Enter the domain and Save
Type the subdomain into the Custom referral domain field (placeholder refer.acme.com) and click Save. The value is normalized — scheme, path and trailing dots are stripped and it's lower-cased.
●
Verify the domain
Once saved, click Verify domain. The button shows Checking DNS… while it resolves your CNAME. On success the badge flips from Not verified to Verified and TLS begins provisioning. After that, use Re-check DNS to re-run the check if anything changes.

Until verification passes, your partner links keep using the platform domain, so an unverified or mistyped domain can never produce dead links.

Via the API / for agents

There is no dedicated public endpoint for setting the domain — it's saved through the same workspace-settings update the dashboard uses. Two calls are involved.

1. Save the domain as part of the workspace settings patch:

curl -X PATCH https://partli.app/api/workspaces/<slug> \
  -H "content-type: application/json" \
  -d '{"referralDomain": "refer.acme.com"}'

2. Verify DNS and provision TLS. This checks the DNS for the domain already saved on the workspace, marks it verified, and best-effort provisions a certificate:

curl -X POST https://partli.app/api/workspaces/<slug>/domain/verify

On success:

{
  "verified": true,
  "via": "cname",              // or "a_record"
  "tls": {
    "provisioned": true,
    "note": "TLS certificate is being provisioned — the domain goes live within a couple of minutes."
  }
}

On failure the DNS check returns 422 with { "verified": false, "error": "<reason>" } — and any prior verification is cleared so links fall back to the platform domain. If the plan doesn't include custom_domain, the endpoint returns 402; without manage permission, 403.

Gotchas

Verification is not permanent. Every call to the verify endpoint (including Re-check DNS) re-resolves DNS; if the record has been removed or repointed, verification is cleared and links revert to partli.app automatically.
TLS provisioning is best-effort. DNS verification succeeds independently of the cert step — if the Coolify API isn't configured or the attach fails, the domain must be added to the app's domains manually before HTTPS works.
A subdomain is expected. Apex domains work only if your provider flattens the CNAME to A records that match the app's IPs.
Only the redirect host changes. Click and promo attribution still flow via the partli_cid / partli_promo query params on the redirect, so nothing about tracking changes when you switch domains.

PreviousEmail campaigns Next AI copy generation